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CC1TT Signalling System fi\So„ 7 in British Telecom's 
Network 

FOREWORD 


The four corner-stones of modern telecommunications networks are digital transmission, 
digital switching, processor control and common-channel signalling. The importance 
of signalling has always been recognised within the telecommunications engineering 
profession and the introduction of the common-channel technique has increased this 
importance considerably, bringing signalling from the realms of point-to-point and 
circuit-by-circuit considerations to an all-pervasive influence throughout the network 
and the controlling software. Without common-channel signalling, we would be hard- 
pressed to provide many of the new and enhanced services our customers now expect, and 
network management would become increasingly difficult with the growing complexity of 
our operations. This issue of the Journal is devoted to the subject of the CCITT 
Signalling System No. 7, the internationally agreed approach to common-channel 
signalling which British Telecom has adopted extensively. 

The concept of common-channel signalling for telecommunications first took shape 
during the 1964-68 CCITT study period and led to the CCITT Signalling System 
No. 6, devised primarily for use at 2-4 kbit/s over analogue bearers on international 
links. This system offered increased signalling speed and capacity and was an ideal 
means for exploiting the benefits of the new processor-controlled international switching 
centres. 

The introduction of digital transmission and switching into new system developments 
such as System X necessitated some rethink of the type of common-channel signalling 
system required in digital networks. Fortunately, this was recognised as an international 
issue and during 1972-1976, CCITT Study Group XI addressed a question on ‘Signalling 
arrangements for integrated digital telephone networks’, and Signalling System No. 7 
was conceived. In 1980, the major Recommendations were presented to the CCITT 
Plenary Assembly and Signalling System No. 7 was born, at least on paper. In parallel 
with the further development of these Recommendations, a number of organisations 
embarked on trial implementations, and one of the first working systems was introduced 
in September 1983 between the UK and Belgium. Also in 1983, British Telecom 
completed the necessary specification work for CCITT Signalling System No. 7 to 
become the mainstay of its extensive digitalisation programme, based initially on System 
X, but now including other systems. 

This long period from initial concept to network realisation is one of the major 
challenges now facing the international standards-making process and, although the 
development of the Signalling System No. 7 Recommendations in the CCITT has 
involved considerable effort and dedication by the experts participating in the study 
groups, it has to be said that the complete output is still not available in time for the 
implementors. The result is the inevitable creation of national or interim standards 
based on the CCITT Recommendations, but extending and enhancing them in ways 
needed for system and network realisation. The consequence is that it then becomes 
more difficult to achieve international agreement on single solutions for which proprietary 
or regional specifications have already been produced or implemented. It must be 
recognised that implementation of such a complex and advanced system and its 
introduction into a network involves considerable investment of skilled resources and 
finance, and cannot easily be overturned by new agreements if these necessitate 
retrospective change. Thus, the challenge to the technical experts is to find ways of 
producing results more quickly, but at the same time to ensure that they will stand the 
test of time and provide the basis for yet further advance. 

The basic concepts of Signalling System No. 7 are certainly standing the test of time 
as major new applications are being added. One of the key features enabling this to 
happen has been the adoption of a layered structure for the specifications. This predates 
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the now famous OSI 7-layer model and in some respects differs from it but, nevertheless, 
is a practical and convincing demonstration of the value of such an approach. The 
articles in this Journal reveal the flexibility available at the Application Level (User 
Part), but also show the emergence of further sub-levels as a means of coping with the 
complexity of the new capabilities. 

One of the current challenges facing network operators is the concept of the integrated 
services digital network (ISDN). The digital transmission and switching facilities now 
deployed in many telephone networks offer an important opportunity to carry non-voice 
services in a more efficient way than an audio signal. However, such use requires 
extensions to the network control and signalling capabilities. Signalling System No. 7 
provides an ideal basis for this, but needs an enhanced or new user part to provide the 
required features. British Telecom’s approach has been to include necessary features 
for ISDN in its national user part, and this enables the current digital network to 
operate as an ISDN. Internationally, work on an ISDN user part is progressing although 
considerable further work will be necessary during the 1988-1992 CCITT study period. 
In the meantime, the European administrations and network operators have agreed, in 
CEPT, an enhanced version of the telephony user part (known as TUP +) as a means 
of interconnecting their networks for provision of international ISDN within Europe at 
an early date, and then to evolve to the ISDN user part. 

One of the key features of ISDN is the extension of common-channel signalling from 
network to terminal equipment. This makes considerable sense when one considers that 
the same digital revolution has taken place on both sides of the terminal-network 
boundary. However, the major challenge is to ensure that the signalling system and 
protocols used here complement the use of Signalling System No. 7 within the network. 
An additional challenge is that increasingly complex network configurations and appli¬ 
cations are emerging, and the ISDN may only be one link in a chain involving local 
area networks, private networks and other forms of public network. The conceptual 
boundaries between public and private telecommunications and between information 
processing and telecommunications are fast disappearing even if the structural bound¬ 
aries within and between organisations may last a while longer. 

In the excitement of new concepts and the whirl of international discussion, it is all 
too easy to overlook the support activities that are essential for the successful introduction 
and operation of networks. In particular, a comprehensive testing capability is required 
both to assist with system development and proving, and also to help deal with the 
inevitable problems that emerge during service. As described in this Journal , British 
Telecom has built up extensive facilities and experience in this area in order to handle 
a situation involving several separate organisations and a number of major systems. 

For British Telecom, CCITT Signalling System No. 7 is a considerable success and 
is now an established workhorse within our extensive digital network. We look forward 
to extending its field of application both for interconnection with other operators and 
for evolution of services. We are particularly interested in the development of standards 
in several areas including ISDN, mobile telecommunications and operations and main¬ 
tenance. There is a need for these standards to be both timely and complete and British 
Telecom will continue to play a full part in the process of international standardisation 
based on our practical experience of network realisation and our commercial needs in 
an increasingly competitive market-place. 


G. P. OLIVER 

General Manager Standards, British Telecom 
Research and Technology 
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CC1TT Signalling System Wo- 7 : Overview 

K. G. FRETTEN, and C. G. DAVIES, m.b.i.m t 
UDC 621.395.34 

This article is an overview of CCITT Signalling System No. 7 and its application to BVs evolving 
network. The structure of BVs current version of CCITT No. 7 signalling is described together with 
indications of proposed enhancements expected to take place in the late-1980s and early-1990s. 
Later articles describe in detail the various component parts which make up BVs CCITT No. 7 
signalling and how it is tested within BVs network. 

This article was originally published in the October 1987 issue of the Journal and is reprinted 
here as an introduction to this series of articles on CCITT No. 7 signalling. 


INTRODUCTION 

The CCITT Signalling System No. 7 (CCITT 
No. 7) is a common-channel signalling system 
in which information can be transported 
between two stored-program controlled 
(SPC) exchanges over a single high-speed 
communications channel (64 kbit/s) by 
means of labelled messages. The signalling 
information relates to a large number of cir¬ 
cuits and provides the capability to implement 
a variety of new services, including many that 
are based on the integrated services digital 
network (ISDN). BT regards CCITT No. 7 
signalling as one of the key elements in the 
development of its telecommunications net¬ 
work and as a result has been implementing 
this standard over the last three years on all 
its digital exchanges (System X et al). 

This article gives an overview of the struc¬ 
ture of CCITT No. 7 signalling, the national 
specifications currently being adopted in BT’s 
network and gives an insight into likely future 
evolution in relation to ongoing CCITT stu¬ 
dies during the 1984-88 period. 

STRUCTURE OF THE SIGNALLING 
SYSTEM 

When CCITT No. 7 signalling was first speci¬ 
fied, its main purpose was to set up and release 
physical circuits between digital exchanges 
for telephony-type services. 

To take account of the wide range of appli¬ 
cations that were foreseen for the signalling 
system, it was designed on a very modular 
functional basis. The transport mechanism is 
application independent, and it is this feature 
that is one of the principal strengths of CCITT 
No. 7 signalling. 

Figure 1 shows schematically the structure 
of CCITT No. 7 signalling. 

BT’s version currently comprises two main 
parts: 


t Network Planning and Works Department, Bri¬ 
tish Telecom UK Communications 


• Message transfer part (MTP) this is 
common for all applications. It transfers sig¬ 
nalling messages over the network and per¬ 
forms subsidiary functions such as error con¬ 
trol. 

The MTP has a three-level hierarchical 
structure: 

(a) Level 1—encompasses the physical sig¬ 
nalling data link, which in a digital network 
consists of a 64 kbit/s time-slot in a PCM 
system. In most cases, time-slot 16 is used; 
however, there is nothing that prevents any 
time-slot except time-slot 0 from being used. 

(b) Level 2—encompasses the signalling 
terminal together with functions for adaption 
between the processor software signals and 
the bit stream of the signalling data link. 
Fields for error detection and correction are 
added by the signalling terminal to ensure 
error-free transmission. These fields are ana¬ 
lysed in the receiving signalling terminal, and 
repetition is requested if an error is detected. 

(c) Level 3—comprises the signalling net¬ 
work functions, including transfer of mess¬ 
ages, reconfiguration of routes after failure, 
or sending information about abnormal situ¬ 
ations in the signalling network. 

• User part this is application dependent. 
Within BT, this is termed the national user 
part (NUP) and is known as Level 4. The 
NUP defines the functions and procedures 
that control both telephone and ISDN-type 
calls and circuits; for example, the signalling 
information to be exchanged between the swit¬ 
ching centres, and the various signals that 
should be used. 

NATIONAL SPECIFICATIONS FOR 
CCITT SIGNALLING SYSTEM No. 7 

Because of its intended versatility and 
reliability, the specification for CCITT No. 7 
signalling is very complex, and occupies 
approximately 450 pages of text simply to 
cover the MTP and user part areas in CCITT 
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Figure 1 

Relationship between 
CCITT No. 7 Functional 
Levels and OSI layering 
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OSI: open systems interconnection 
SCCP: signalling connection control part 
TCAP: transaction capabilities application part 


Recommendations Q.701-Q.707 and 
Q.721-Q.725. 

When BT decided to specify its network 
requirements for CCITT No. 7 signalling 
some four to five years ago, the CCITT Rec¬ 
ommendations were used as base documents; 
however, the level of detail and the scope of 
the information was found to be inadequate 
for implementation purposes, hence BT prod¬ 
uced its own series of specifications. 

Message Transfer Part 

The BT implementation of the MTP is speci¬ 
fied in BTNR 146 (British Telecom Network 
Requirement) and BTNR 167 Issue 2 and is 
based very closely on the CCITT Recommen¬ 
dations. Even so, the MTP(BT) differs from 
that adopted in many other countries for two 
reasons: 

(a) The CCITT Recommendations allow 
for a number of national options. An example 
of this is that the CCITT Recommendation 
allows load sharing either within a linkset or 
between linksets; BT has implemented load 
sharing with a linkset and requires an even 
distribution of traffic to available links. 

( b ) In some cases, the CCITT Recommen¬ 
dation is not sufficiently complete to allow 
implementation in practical networks. An 
example of this is that a load-sharing algor¬ 
ithm is necessary before implementation can 
take place; however, this is not specified in 
the CCITT Recommendations. 

National User Part 

The BT NUP specification (BTNR 167) 


differs from that of CCITT in a number of 
areas. The main reason for these differences is 
that when BT was specifying the requirements 
for its digital network in the late-1970s and 
early-80s, the CCITT was concentrating on 
the telephony user part (TUP). Hence, whilst 
using the studies as a basis for the NUP, 
additional features were added to incorporate 
ISDN capabilities. Examples of these are: 

(a) The TUP procedures allowed infor¬ 
mation to be passed only on a link-by-link 
basis. In an ISDN environment, it is necessary 
to provide end-to-end procedures to allow ser¬ 
vices to be provided on the periphery of the 
network without changing all nodes in the 
network. These concepts are now being intro¬ 
duced in the CCITT. 

( b ) CCITT Recommendations do not take 
account adequately of the existence of more 
than one version of CCITT No. 7 signalling. 
BT adopted a ‘confusion’ message to deter¬ 
mine the level of implementation in other 
nodes of a network. This concept has only 
recently been addressed in CCITT. 

The adventurous decision to aim for an 
early implementation of the ISDN within 
BT’s network has resulted in BT’s MTP and 
NUP specifications of CCITT No. 7 signal¬ 
ling having to predict the direction CCITT 
would go in areas that had not been 
adequately specified. 

The BT specifications for CCITT No. 7 
signalling have recently been completed for 
the ISDN Phase 3 development programme of 
the network, and many sophisticated services 
have been incorporated. The process of 
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deriving a specification which allows different 
exchange manufacturers to develop the signal¬ 
ling system independently of each other, 
whilst ensuring interworking occurs, is enor¬ 
mous. Currently the specification is in excess 
of 1000 pages of text and drawings. 

EVOLUTION OF NO. 7 SIGNALLING AND 
ASSOCIATED SPECIFICATIONS 

During the 1980-1984 study period, the 
CCITT extended No. 7 signalling by the 
introduction of three additional parts which 
were published in the 1984 Red Book: 

# the signalling connection control part 
(SCCP), 

@ the operations and maintenance appli¬ 
cation part (OMAP), 

• the ISDN user part (ISUP). 

During the current CCITT study period 
1984-1988, work is continuing on the above 
topics with the addition of another part called 
transaction capabilities applications part 
(TCAP). 

A brief review of each of the newly specified 
parts is given below: 

Signalling connection control part The 
SCCP has two basic purposes: it allows infor¬ 
mation to be exchanged between network 
nodes that are not connected by telephony 
circuits, and it provides addressing capabili¬ 
ties between nodes connected to the same or 
different signalling networks. 

Operations and maintenance application 
part The OMAP defines procedures for 
supervising, controlling and testing a signal¬ 
ling network. In addition, it may also enable 
the transfer of bulk data to be undertaken by 
the signalling network and carry management 
commands relating to the operation of the 
main network. 

ISDN user part The ISUP is designed 
basically for the provision of ISDN services 
within the switched network. It also defines 
new principles in network signalling, such as 
symmetrical release of circuits under calling- 
or called-party control etc. The ISUP is under¬ 
going considerable revision in the current 
study period ready for publication in the 1988 
Blue Book Recommendations. 

Transaction capabilities application part 
The TCAP is somewhat unusual in that, 
although it is part of the application layer 
(the layer that provides real applications or 
services), it does not offer any real services. 
What it does offer is a standard structuring 
technique for non circuit-related applications 
which should simplify the task of defining 
application protocols. 

Evolution of BT's CCITT No. 7 Signalling 
System 

As mentioned earlier, one of the reasons why 
CCITT No. 7 signalling is such a powerful 
tool is that it was designed with evolutionary 


potential as a key objective. From an overall 
point of view, the circuit-related mode of BT’s 
version of CCITT No. 7 signalling has become 
stabilised (MTP and NUP). One possible 
enhancement in the future would be the adop¬ 
tion of the ISUP. This is not foreseen for some 
time in BT’s network since the NUP has 
greater capabilities than the present proposals 
for the CCITT Recommendation. The use of 
the ISDN user part at international gateways 
will rely on bilateral agreements with other 
countries and consequential commercial cri¬ 
teria. 

The most likely enhancements will be for 
non-circuit-related transactions to support 
services expected to be introduced in the early 
1990s, for example, access to databases etc. 
This implies the introduction of SCCP and 
TCAP protocols in the network. 

SUMMARY 

With the introduction of its digital exchanges, 
BT has been implementing CCITT No. 7 sig¬ 
nalling as one of the key elements in the 
development of its telecommunications net¬ 
work. By virtue of this early implementation 
of the signalling sytem before the appropriate 
CCITT Recommendations had stabilised, an 
element of prediction was necessary for those 
areas that had not been completely specified. 
Other articles in this series describe how the 
various parts of the CCITT No. 7 signalling 
system have been implemented in BT’s net¬ 
work. 
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CC1TT Signalling System No. 7 : Message l ransfer 
Part 

B. LAW, T.eng., M.I.ELEC.I.E., and C. A. WADSWORTH, t.eng., m.i.elec.i.e.1* 

UDC 621.395.34 

This article is one of a series of articles on CCITT Signalling System No. 7 and its application to 
the British Telecom network. It considers the message transfer part (MTP). A description of the 
functions of the constituent levels of the MTP is given to provide an understanding of its purpose 
in CCITT No. 7 signalling. Differences between the signalling system as specified by the CCITT and 
the requirement for the British Telecom network are identified, together with the activity within the 
CCITT to achieve as close alignment as possible. The evolution of the MTP in the light of 
developments in other parts of CCITT No. 7 signalling is also examined. 


INTRODUCTION 

Communication between stored-program- 
controlled (SPC) exchanges in the British 
Telecom network requires a fast reliable high- 
capacity signalling system, capable of oper¬ 
ating in a digital transmission environment. 
An article[l] in a previous issue of this 
Journal has described how this is realised 
in the BT network with a common-channel 
signalling system based on CCITT No. 7 sig¬ 
nalling^]. The modular nature of this signal¬ 
ling system makes it flexible and adaptable 
for a number of uses, but no matter what use 
is made of the signalling information carried, 
or what user part[3, 4] is implemented at an 
exchange, the message transfer part (MTP) 
is always required. 

Figure 1 

General structure of--- 

signalling system t CCITT No. 7 Signalling Standards Group, Bri- 

functions tish Telecom UK Communications 



-Signalling message How-Controls and indications 

TUP Telephone user part DUP Data user part 


The MTP provides the functions that enable 
user part significant information passed to the 
MTP to be transferred across the CCITT 
No. 7 signalling network in message signal 
units (MSUs) to the required destination. 
Mechanisms are provided in the MTP that 
ensure MSUs are received in the correct 
sequence, any errors detected, and, if required, 
messages retransmitted. In addition, further 
procedures ensure that the impact of network 
or system failures have minimal effect on the 
ability of the MTP to transfer MSUs. 

The functions performed by the MTP are 
specified in terms of the level in which they 
are located; therefore the modular concept is 
as true of the MTP as the rest of CCITT 
No. 7 signalling. This ‘level’ approach is the 
basis of all the work in the MTP, and is 
used in this article to explain how the MTP 
functions and performs its data transfer and 
management tasks. There should be a clear 
understanding that levels in CCITT No. 7 
signalling do not always relate directly to the 
equivalent OSI layer[5]. 

LEVELS IN THE MTP AND POSITION IN 
THE CCITT No. 7 ARCHITECTURE 

The MTP consists of three levels (Levels 1-3 
of CCITT No. 7), and this structure is 
depicted in Figure 1. 

The Level 1 functions provide the data link, 
which is a bi-directional transmission path 
for signalling comprising two data channels 
operating together in opposite directions at 
the same data rate. The data rate normally 
chosen for CCITT No. 7 signalling is 
64 kbit/s[6], but lower rates down to 
4-8 kbit/s can be used. 

The transmission path is normally provided 
over digital plant extracting a spare time-slot 
from a 32 time-slot 2048 kbit/s system. It is 
possible, however, to use analogue line plant 
with a suitable modem providing the appro¬ 
priate interface to the signalling terminal 
(CCITT No. 7 Level 2 functions). The 
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Level 1 functions of the MTP, although 
included in the CCITT Recommendations, 
are not specific to the signalling system, and 
are more fully documented in the appropriate 
transmission Recommendations. 

In the BT network, the signalling data links 
are normally provided by using time-slot 16 
(TS16) from a 32 time-slot 2048 kbit/s 
system. This will normally be connected to the 
appropriate Level 2 realisation at an exchange 
by means of a semi-permanent path across 
the switch-block[7]. 

Level 2 of the MTP, the signalling link, 
provides the functions and procedures for the 
transfer of signalling messages over one sig¬ 
nalling data link. The signalling link func¬ 
tions, together with the signalling data link as 
bearer, provide a signalling link for reliable 
transfer of signalling messages between two 
directly connected signalling points. 

Level 3 of the MTP provides functions and 
procedures to allow for the transfer of signal¬ 
ling messages between signalling points which 
are part of the CCITT No. 7 signalling net¬ 
work. Specification of the Level 3 functional 
block assumes that signalling links and signal¬ 
ling data links are provided between the sig¬ 
nalling points in the network. 

SIGNALLING NETWORK 
Basic Concepts 

The telecommunications network served by 
common-channel signalling is composed of a 
number of switching and processing nodes 
interconnected by transmission links. To com¬ 
municate using CCITT No. 7 signalling, each 
of these nodes requires to implement the 
necessary ‘within node’ features, making that 
node a signalling point within the CCITT 
No. 7 signalling network. In addition, there is 
a need to interconnect these signalling points 
so that signalling information (data) can be 
conveyed between them. These data links are 
the signalling links of the CCITT No. 7 sig¬ 
nalling network. 

The combination of signalling points and 
their interconnecting signalling links form the 
CCITT No. 7 signalling network. 

Signalling Points 

In specific cases, there may be a need to 
partition the common-channel signalling 
functions at such a (physical) node into logi¬ 
cally separate entities from a signalling net¬ 
work point of view; that is, a given (physical) 
node may be defined as more than one signal¬ 
ling point. One example is an exchange at 
the boundary between the international and 
national signalling networks. 

Any two signalling points, for which the 
possibility of communication between their 
corresponding user part function exists, are 
said to have a signalling relation. 

Examples of nodes in a signalling network 
that constitute signalling points are: 


(a) exchanges (switching centres), 

( b ) operation, administration and mainten¬ 
ance centres, 

(c) intelligent network databases, and 

( d) signalling transfer points. 

All signalling points in a CCITT No. 7 
signalling network are identified by a unique 
code known as a point code. 

Signalling Links 

The common-channel signalling system uses 
signalling links to convey the signalling mess¬ 
ages between two signalling points. A number 
of signalling links that directly interconnect 
two signalling points which are used as a 
module constitute a signalling link-set. 


Signalling Modes 

The term signalling mode refers to the associ¬ 
ation between the path taken by a signalling 
message and the signalling relation to which 
the message refers. In the associated mode 
of signalling, the messages relating to a par¬ 
ticular signalling relation between two 
adjacent points are conveyed over a link-set, 
directly interconnecting those signalling 
points. 

In the non-associated mode of signalling, 
the messages relating to a particular signalling 
relation are conveyed over two or more link- 
sets in tandem, passing through one or more 
signalling points other than those which are 
the origin and the destination of the messages. 
This mode is not specified for CCITT No. 7 
signalling. 

The quasi-associated mode of signalling is 
a limited case of the non-associated mode 
where the path taken by the message through 
the signalling network is predetermined and, 
at a given point in time, fixed. 

Examples of signalling modes are illus¬ 
trated in Figure 2. 


Figure 2 

Example of associated 
and quasi-associated 
signalling modes and 
definition of signalling 
network symbols 


QUASI- QUASI - 



O Signalling point with at least a user function; 

whether or not STP function is present is irrelevent in the context of the diagram. 

□ Signalling point with at least STP function; 

whether or not user function is present is irrelevant in the context of the diagram. 

(^) Signalling point with both user function and STP function 



Signalling Point Modes 

A signalling point at which a message is 
generated (that is, the location of the source 
user part function) is known as the originating 
point of that message. 


8 


British Telecommunications Engineering , Vol. 7, April 1988 









A signalling point to which a message is 
destined (that is, the location of the receiving 
user part function) is known as the destination 
point of that message. 

A signalling point at which a message is 
received on a signalling link and then trans¬ 
ferred to another link (that is, neither the 
location of the source nor the receiving user 
part function) is known as a signal transfer 
point (STP). 

Signalling Routes 

The predetermined path, consisting of a suc¬ 
cession of signalling points and the intercon¬ 
necting signalling links, that a message takes 
through the signalling network between the 
origination point and the destination point is 
the signalling route for that signalling 
relation. 

All the signalling routes that may be used 
between an originating point and a destination 
point by a message traversing the signalling 
network is known as the signalling route set 
for that signalling relation. 

Signalling Network Structure 

The structure of the signalling network 
depends greatly on the type of network that 
has to be supported. For example, with a 
public switched network, the signalling net¬ 
work carries mainly call-control signalling 
traffic, and its structure closely follows that of 
the switching network; that is, predominantly 
associated signalling with some quasi-associ¬ 
ated stand-by. For a network regarded as a 
common data transfer resource, the structure 
is likely to be quasi-associated with associated 
signalling on high-density routes. The world¬ 
wide signalling network structure comprises 
the individual national networks connected 
via the international network. 

LEVEL 2 

The MTP Level 2 comprises functions which 
facilitate the reliable transfer of messages 
over a single signalling link. These functions 
ensure that messages are delivered in the 
correct order, and without loss or duplication, 
on a link having line error rates up to a 
specified limit. Error rates higher than this 
specified limit cause the link to be failed. 

Signal Units 

Signalling information is transferred between 
the nodes at each end of a signalling link in 
signal units. Each signal unit is delimited (the 
beginning and end marked) by a unique 8 bit 
pattern called a flag. 

Three types of signal unit exist: 

• fill in signal units (FISUs) which are nor¬ 
mally sent when no messages are available for 
transmission, 

• link status signal units (LSSUs) which are 
used in the control of the link, and 


# message signal units (MSUs) which carry 
the user part information. 

Signal formats are shown in Figure 3. Note 
that the coding of the length indicator, which 
is common to all types, is the means of ident¬ 
ifying to which of the three types a signal unit Figure 3 
belongs. Signal unit formats 
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( a ) Format of a fill-in signal unit 
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(6) Format of a link status signal unit 
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( c ) Basic format of a message signal unit 


BIB: Backward indicator bit 
BSN: Backward sequence number 
CK: Check bits 
F: Flag 

FIB: Forward indicator bit 


FSN: Forward sequence number 
LI: Length indicator 
SF: Status field 

SIF: Signalling information field 
SIO: Service information octet 


Fill In Signal Units 

The forward and backward indicator bits, and 
forward and backward sequence numbers are 
used in the basic error control procedure to 
perform the signal unit sequence control and 
acknowledgement functions. 

The check bits are used for error detection. 

Link Status Signal Units 

LSSUs have the same format as FISUs except 
for the addition of the status field which 
indicates the link status as follows: 

Status indication «out of alignment’ 
(SIO) is transmitted when an initial align¬ 
ment procedure has been started and none of 
the status indications SIO, SIN, or SIE is 
received from the signalling point at the far 
end of the link. 

Status indication ‘normal’ (SIN) is trans¬ 
mitted when, after initial alignment has been 
started, status indication SIO, SIN, or SIE is 
received, and the terminal is in the normal 
alignment state. 

Status indication <emergency’ (SIE) is 
transmitted when, after initial alignment has 
been started, status indication SIO, SIN, or 
SIE is received, and the terminal is in the 
emergency alignment state. 


British Telecommunications Engineering , Vol. 7, April 1988 


9 





































Status indication 'out of service ' 
(SIOS) is transmitted to inform the remote 
end of the link that the transmitting signalling 
link terminal cannot, for reasons other than 
processor outage, receive or transmit MSUs. 

Status indication 'processor outage 9 
(SIPO) is transmitted to inform the remote 
end of the link that the transmitting signalling 
link terminal cannot receive or transmit 
MSUs, owing to processor outage; that is, 
caused by failure conditions at a functional 
level above Level 2. 

Status indication 'busy* (SIB) is trans¬ 
mitted to inform the remote end of the link 
that the transmitting signalling link terminal 
is operating under Level 2 congestion con¬ 
ditions. 

Message Signal Units 

MSUs have exactly the same format as a 
FISU except for the addition of a service 
information octet and the signalling infor¬ 
mation field which are used at levels above 
Level 2 as described in the section on Level 3 
below. 

Error Detection and Correction 

Sixteen check bits are included at the end of 
each signal unit to enable errors to be 
detected. The transmitting signalling link ter¬ 
minal generates these check bits by operating 
on the preceding bits in the signal unit in 
accordance with a specified algorithm. The 
signalling unit and check bits are checked at 
the receiving signalling link terminal. Signal 
units found to be in error are discarded. 

Two forms of error correction are rec¬ 
ommended by the CCITT: the basic method 
which is suitable for signalling links where the 
one-way propagation delay is less than 15 ms; 
and the preventative cyclic retransmission 
method which is suitable for propagation 
delays in excess of 15 ms. BT uses the former 
type, which employs positive and negative 
acknowledgements indicated by the forward 
and backward sequence numbers and the for¬ 
ward and backward indicator bits. 

When a signal unit is transmitted, a copy 
is retained at the transmitting signalling link 
terminal until a positive acknowledgement for 
that signal unit is received. If a negative 
acknowledgement is received, then the trans¬ 
mission of new signal units is interrupted until 
those signal units which have been transmitted 
but not positively acknowledged have been 
retransmitted. This retransmission com¬ 
mences with the signal unit indicated by the 
negative acknowledgement, and continues in 
the order they were first transmitted. 

Alignment 

Before a link can enter service, an alignment 
procedure is used to ensure that it is capable 
of operating above a certain performance. 


This procedure is used when a link is brought 
into service and when service is being restored 
after a break. It includes a proving period 
which, by instruction from Level 3, can be 
either a ‘normal’ period of the transmission 
time of 2 16 octets, or an emergency proving 
period of the transmission time of 2 12 octets. 
During the proving period, the error rate of 
the link is monitored. 

Processor Outage 

Processor outage procedure operates when use 
of a link is precluded owing to problems at 
a functional level higher than Level 2; for 
example, a centralised processor failure. 
When Level 2 recognises, or is informed of 
this state, it transmits SIPO on the link and 
discards received message signal units. The 
receiving Level 2 at the distant end, if it is in 
its normal mode sending MSUs or FISUs, 
notifies its Level 3 and sends FISUs continu¬ 
ously. When the processor outage condition 
reverts to normal, SIPO is withdrawn and the 
transmitting end transmits MSUs or FISUs. 
The receiving end also returns to normal oper¬ 
ation after informing Level 3. 

Signalling Link Error Monitoring 

Level 2 contains two link error rate monitor 
functions: one, the signal unit error rate 
monitor, which is used whilst a signalling link 
is in service to determine whether or not 
the link is fit for service; and the other, the 
alignment error rate monitor, which is used 
during the proving period of the initial align¬ 
ment procedure. 

Flow Control 

When congestion at Level 2 is detected at the 
receiving end of the link (by an implementa¬ 
tion-dependent means), both positive and 
negative acknowledgements are withheld and 
status indication \busy ' (SIB) is returned to 
the transmitting end, so that the latter can 
distinguish between failure and congestion 
conditions. A supervision timer is started on 
receipt of SIB and, should it mature before 
normal operation of the link is restored, link 
failure indication is generated. 

LEVEL 3 

In addition to the ability to transfer messages 
under normal fault-free conditions, the signal¬ 
ling network functions (Level 3) of the MTP 
must ensure the reliable transfer of signalling 
messages to a specified standard even in the 
case of network failures; that is, failure of 
signalling links or signalling transfer points 
(STPs). Therefore, appropriate functions and 
procedures must be included at Level 3 which 
both inform the remote parts of the signalling 
network of the consequences of failures, and 
reconfigure the routing of messages through 
the signalling network to overcome them. 
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Figure 4 

Signalling network 
functions 


The signalling network functions can be 
divided into two basic categories: 

• signalling message handling (SMH), and 
$ signalling network management (SNM). 

The distribution of these functional blocks 
within Level 3 is shown in Figure 4. 


LEVEL 4 LEVEL 3 LEVEL 2 

USER MESSAGE 

PARTS MESSAGE TRANSFER PART TRANSFER 



-Signalling message flow 

-Controls and indications 


Signalling Message Handling 

The SMH function enables signalling mess¬ 
ages originated by a user part at a signalling 
point to be delivered to the corresponding user 
part at the required destination signalling 
point. Address information is contained in the 
routing label that is present in every message. 
The routing process is situated in the outgoing 
signalling point and, in accordance with the 
information contained in the message routing 
label, directs the message onto the correct 
route to reach the required destination. 

The other functional blocks situated in 
SMH on the incoming side at a signalling 
point are the message discrimination and 
message distribution processes. The message 
discrimination process examines the message 
routing label and, from the information con¬ 
tained in the destination address portion, 
determines whether the message should be 
onward routed (that is, the STP function 
invoked) or delivered to a user part at that 
signalling point. 

Messages to be onward routed are delivered 
to the routing process, while those to be 
directed to a local user part are passed to 
the message distribution process. This latter 
process examines the part of the message that 


identifies the user part to which the message 
information refers and delivers the signalling 
information in the message to that user part. 

Within the routing process there is a further 
mechanism which enables messages to be 
directed over a particular signalling link in a 
multi-link route. This is known as load 
sharing and determines the link to be used 
based on information contained in the 
message routing label and a locally-produced 
algorithm. For some network management 
messages, this load sharing information in 
the label identifies by its signalling link code 
(SLC) the actual link over which the message 
is to be sent (or not sent), and no algorithm 
is required. Two forms of load sharing are 
specified by the CCITT: within link-set , and 
between link-sets. These two scenarios are 
depicted in Figure 5. The BT network require¬ 
ments call for the use of only within link-set 
load sharing. 


_ = XXMJ_ _a 

-1-/b\ 

-► SLS = XXXI 1 -* 

(a) Example of load sharing within a link set 



(b) Example of load sharing between link sets 


Figure 5—Load sharing 


A message delivered to the MTP and pro¬ 
cessed by Level 2 (that is, Level 2 headers 
added) becomes a message signal unit (MSU) 
for transmission in the CCITT No. 7 signal¬ 
ling network. The components of the MSU 
used by SMH are shown in Figure 6. The 
routing label comprises the destination point 


INFORMATION USED AT LEVEL 3 

A- 


LEVEL 2 

USER INFORMATION 

SLS 

OPC 

DPC 

SIO 

LEVEL 2 


N ~ -v- ' 

SIGNALLING INFORMATION FIELD (USED AT LEVEL 4) 


DPC: Destination point code 
OPC: Originating point code 
SIO: Service information octet 
SLS: Signalling link selection 

Figure 6—Components of MSU used by SMH 


code (DPC), originating point code (OPC), 
and signalling link selection (SLS) and is 
shown in Figure 7. 

The DPC is the information used by the 
routing process to determine the destination 
and, therefore, the signalling route over which 
the MSU should be directed. The SLS, which 
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Signalling network management comprises 
three main functions: 


USER 

INFORMATION 

SLS 

OPC 

DPC 

LENGTH 0X8 
(BIT) (0>O) 

4 14 14 

ROUTING LABEL 

LABEL 


9 signalling traffic management, 

# signalling link management, and 

• signalling route management. 


DPC: Destination point code 
OPC: Originating point code 
SLS: Signalling link selection 

Figure 7—Routing label structure 

is the four least significant bits of the circuit 
identification code (CIC) when the messages 
are generated by the national user part 
(NUP), is used by the load-sharing mech¬ 
anism to determine the actual link to be used. 
The OPC identifies the signalling point at 
which the MSU originated. 

The DPC is also used by the message dis¬ 
crimination process to determine whether the 
MSU is for a local user part or is to be onward 
routed, using the node’s STP function. 

The service information octet (SIO), 
Figure 8, contains the service indicator, which 
determines the user part that the signalling 
information should be delivered to by the 
distribution function. In addition to the service 
indicator, the SIO also contains a 4 bit sub¬ 
service field, bits C and D of which form the 
network indicator (NI). 


DCBA 

OCBA 


SUB-SERVICE 

SERVICE 


FIELD 

INDICATOR 


4 

4 

First bit transmitted 


Figure 8—Service information octet 


The NI can be used to distinguish between 
two signalling networks when an exchange is 
common to more than one; for example, an 
international switching centre, which is part 
of both the BT inland network and the inter¬ 
national network, would use this feature. 
Messages can thus be delivered to the national 
or international user part as appropriate and, 
when required, the routing procedure modified 
by examining the NI. 

Signalling Network Management (SNM) 

The main purpose of the MTP Level 3 is 
contained in the SMH functions; that is, the 
delivery of MTP-user signalling messages to 
the correct destination in the CCITT No. 7 
signalling network. To enable this objective 
to be achieved, however, it is essential to have 
mechanisms within the MTP to prevent any 
failures or dislocations within the signalling 
network from having any great impact. Sig¬ 
nalling network management contains the 
functions that provide security against net¬ 
work conditions and enables the MTP to ach¬ 
ieve the required level of reliable information 
transfer. 


Signalling Traffic Management (STM) 

STM enables the MTP to divert signalling 
traffic from a signalling link or route to one 
or more alternative links or routes as the 
current status of the signalling network 
demands for reliable message transfer to be 
maintained. In addition, signalling traffic flow 
towards an affected destination may be regu¬ 
lated should congestion occur at that point in 
the network. To achieve this function, STM 
incorporates the following procedures: 

link changeover, 

link changeback, 

forced re-routing, 

controlled re-routing (equates to change- 
back), and 

signalling traffic flow control. 

In most instances, these procedures take 
place without message loss, but where emerg¬ 
ency procedures are required, some loss may 
be incurred. 

Link changeover is involved when the 
MTP detects that the concerned link is not 
providing the required level of reliable 
message transfer; for example, when the thres¬ 
hold for the signal unit error-rate monitor is 
breached. Messages destined for the link are 
stopped and placed in a buffer and the 
receiving end of the link is contacted. The 
handshake exchange of messages between the 
transmit and receive end of the link enables 
the alternative link to be determined and those 
messages that have been sent but not yet 
acknowledged (and held in the re-trans¬ 
mission buffer), to be identified. These ident¬ 
ified messages are then retrieved from the re¬ 
transmission buffer and, together with the 
already buffered ‘stopped’ messages, sent over 
the alternative signalling link such that the 
message sequence is maintained. Where it is 
not possible for the transmit and receive ends 
of the link to communicate, an emergency 
procedure takes place (that is, without the 
handshake), and in this case some messages 
may be lost. 

Link changeback is the reverse procedure 
to changeover and is invoked when the MTP 
detects or is informed that a previously una¬ 
vailable signalling link can now carry the 
signalling traffic that was previously diverted 
from it. 

Transmission of the signalling traffic on the 
alternative link is stopped and the messages 
placed in the buffer. A handshake procedure 
then takes place between the transmit and 
receive ends of the newly available link and, 
when this has been successfully completed, 
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the buffered traffic is started on the link. 
Should it not be possible for the two ends of 
the link to communicate, a time-controlled 
diversion ensures that messages sent on the 
alternative link are acknowledged before sig¬ 
nalling traffic is sent on the re-started link. 
This procedure therefore avoids any mis-sequ- 
encing. During both changeover and change- 
back procedures, the current status of the 
affected links is always updated at the 
transmit and receive terminals; that is, 
AVAILABLE/UNAVAILABLE. 

Network scenarios depicting the various 
changeover/changeback situations are shown 
in Figure 9. 


Figure 9 

Examples of link 
changeover situations 


OX x o 

(a) Example of changeover to a parallel link 



(b) Example of changeover to a signalling route 
passing through the remote signalling point 



(c) Example of changeover to a signalling route not 
passing through the remote signalling point 



Forced re-routing enables the signalling 
capability to be restored as quickly as possible 
between two points in the signalling network 
should the previous route have failed. The 
procedure ensures that communication is 
restored with the minimum of message loss. 
This is achieved by immediately stopping sig¬ 
nalling traffic from being sent on the failed 
route as soon as this failure is detected. Detec¬ 
tion is either by the receipt of a transfer 
prohibited message (TFP) or the failure of 


the last link in a link-set. When the alternative 
route has been determined, the buffered traffic 
is started on the appropriate link-set and the 
routing tables in the routing function updated. 
Should the signalling point re-routing also be 
an STP, it sends a TFP regarding the affected 
destination over the new route. 

Controlled re-routing enables signalling 
traffic between two signalling points to be 
re-started on the original route when this 
becomes available. Availability is indicated 
either by the receipt of a transfer allowed 
message (TFA) or a previously unavailable 
link-set becoming available. The affected 
traffic on the alternative route is stopped, 
buffered, and a time-out started. When the 
time-out expires, a TFP is sent, if appropriate, 
on the original route relating to the affected 
destination and, starting with the buffered 
messages, signalling traffic re-started on the 
original route and the route marked as avail¬ 
able. The purpose of the time-out is to prevent 
any mis-sequencing from occurring. 

Signalling traffic flow control enables sig¬ 
nalling traffic towards a particular destination 
to be reduced should that part of the network 
become congested. Congestion is detected at 
Level 2 in the MTP and indicated to Level 3 
where the message routing process marks the 
affected destination as congested. 

When message routing receives a message 
for a congested destination, as well as the 
message being passed to Level 2, the signal¬ 
ling traffic flow control is informed. This pro¬ 
cess causes the message originator (user part) 
to be informed by means of an MTP primitive 
that the destination is congested, or, if the 
originator is at a remote signalling point, by 
means of a signalling network management 
message. 

When congestion at the destination abates, 
this change is detected by Level 2, which 
informs Level 3, and the congestion marking 
is then removed from the message routing 
table. 

Similar procedures apply when congestion 
is detected within the signalling point. 

Signalling Link Management (SLM) 

SLM is used to restore failed signalling links, 
activate idle signalling links and de-activate 
aligned links. The following procedures are 
contained in SLM: 

signalling link activation, 
restoration, 
deactivation, 
link-set activation, and 
automatic allocation of signalling terminals 
and data links. 

Signalling link activation enables an 
inactive link to be brought into service. After 
the initiation of the activation procedure, 
Level 2 alignment takes place and when this 
has successfully been completed a signalling 
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link test is started. On the successful com¬ 
pletion of this test, the link is marked as 
available and signalling traffic started on it. 

Should Level 2 alignment not be successful, 
a time-out is started and activation re¬ 
attempted. The value of the time-out is set so 
that the level alignment procedures are not 
compromised. 

Signalling link restoration is used to 
bring a failed signalling link back into service. 
Failure may be as a result of an error rate 
monitor threshold being exceeded or an unsuc¬ 
cessful signalling link test. When restoration 
is initiated, the link is aligned at Level 2 and 
a signalling test carried out. The successful 
completion of the signalling link test causes 
the link to be marked as available and resto¬ 
ration is complete. 

Signalling link deactivation enables a 
link to be taken out of service provided no 
signalling traffic is carried on that link. 

Link-set activation incorporates two pro¬ 
cedures for normal and emergency re-start. 
Normal activation applies when a link-set is 
brought into service for the first time, and re¬ 
start applies when a previously faulty link-set 
becomes available or nodal functions (such 
as processor re-start) makes it necessary to 
establish a non-emergency link-set. Link acti¬ 
vation takes place on each link in parallel 
until all links are available. However, traffic 
can be started on each link in turn as it 
becomes available. 

Emergency activation is required when sig¬ 
nalling traffic is being blocked or it is not 
possible to communicate with a remote signal¬ 
ling point. In these instances, activation starts 
on as many links in the link-set as possible. 
Activation of the links, however, uses the 
emergency alignment and proving periods. 

Automatic allocation of data links and 
terminals employs procedures based on 
normal activation, restoration etc., but since 
there is no fixed relation between signalling 
data links and terminals, greater flexibility in 
providing signalling links is achieved. The 
procedures are, therefore, more complex than 
with basic link management and, for auto¬ 
matic signalling data link allocation, 
additional signalling network management 
messages are required. These automatic pro¬ 
cedures are not used in the BT CCITT No. 7 
signalling network. 

Management inhibiting is a procedure in 
addition to the normal signalling link manage¬ 
ment and allows a signalling link to be 
removed from service for normal signalling 
traffic while maintaining its availability for 
test traffic etc. The procedure consists of a 
handshake procedure between transmit and 
receive ends of the link to obtain permission 
to inhibit. When this is granted, normal sig¬ 
nalling traffic to that link is diverted to a 
nominated stand-by and the link marked as 


inhibited. The link becomes uninhibited when 
the purpose for inhibiting has been satisfied 
or, should subsequent failures require it, a 
forced uninhibit procedure automatically 
restores the link to service. 


Signalling Route Management (SRM) 

The signalling route management (SRM) 
functional block contains procedures that are 
used to exchange signalling management 
information in the network regarding the net¬ 
work status so that the network may be recon¬ 
figured (by blocking/unblocking routes etc.) 
to provide the most efficient message routing. 
The following procedures are contained in 
SRM: 


transfer prohibited procedure, 
transfer allowed procedure, 
signalling route-set test procedure, 
transfer controlled procedure, 
transfer restricted ) National 

procedure, and ) options 

signalling route-set ) not adopted 

congestion test. ) by BT 


Transfer prohibited procedure enables 
information to be sent to all concerned points 
that a signalling route is no longer available 
for the transport of signalling messages across 
the CCITT No. 7 network. Use is made of 
the transfer prohibited message (TFP), which 
is broadcast by an STP when it detects that 
signalling messages cannot be delivered to a 
specific destination. The TFP is also sent in 
the response mode when a message is received 
(including test messages) for the affected des¬ 
tination, and over an alternative route before 
traffic is started on it to prevent abortive 
circular routing during multiple link failure. 
The receipt of a TFP causes the signalling 
point to update its routing tables and, should 
TFPs be received for all routes to a specific 
destination, local user parts are informed that 
the destination (route set) is unavailable. 


Transfer allowed procedure enables the 
network to be informed that a previously una¬ 
vailable route can once more be used to trans¬ 
port signalling messages across the CCITT 
No. 7 network. The transfer allowed message 
(TFA) is broadcast by an STP when it detects 
that signalling messages can be sent to a 
particular destination that previously could 
not be reached. The TFA is also sent in the 
response mode when a test message, indi¬ 
cating that the destination is believed unavail¬ 
able, is received. When a signalling point 
receives a TFA, the routing tables are updated 
accordingly. Should a TFA be received for a 
destination that was previously marked una¬ 
vailable, local users are informed that the 
concerned destination (route-set) is now avail¬ 
able and signalling traffic can be re-started. 


Route-set test procedure enables a signal¬ 
ling point to acquire knowledge of the status 
of the signalling network. The route-set test 
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Figure 10 
Signalling network 
message format 


message (RST) is sent towards STPs for 
various reasons as follows: 

(a) in response to a TFP from an adjacent 
STP, 

(b) when a previously unavailable STP can 
once more be reached (this proves all routes 
via the STP before traffic is restarted), and 

(c) as a periodic signalling network man¬ 
agement message, enabling the status of the 
network to be continuously audited. 

On receipt of an RST at the STP, should 
the status of the destination have changed 
(that is, now available), then an appropriate 
response (TFA) is made. If the destination 
status is unchanged, no response is made when 
an RST is received. The signalling point 
sending the RST, on receipt of a response, 
updates the status of the route concerned in 
the routing table. 

Transfer controlled procedure is used to 
enable signalling traffic flow control to be 
exercised in the CCITT No. 7 network. The 
transfer controlled message (TFC) is sent by 
an STP towards the message origin whenever 
a message is received for a congested desti¬ 
nation. The receipt of the TFC at the orig¬ 
inating signalling point causes an indication 
that the destination is congested to be sent to 
the user parts. 

Transfer restricted procedure makes use 
of the transfer restricted message (TFR) to 
inform signalling points in the CCITT No. 7 
signalling network that an STP is having 
difficulty in transferring messages towards a 
particular destination. The originating signal¬ 
ling point then decides if a more advantageous 
route can be used. This procedure is a national 
option which is not used in the BT network. 

Route-Set Congestion Test Procedure is 
used to determine the level of congestion in 
networks which employ a message priority 
procedure in the signalling traffic flow control 
mechanism. It is a national option not used in 
the BT network. 

Signalling Network Management 
Message Formats and Codes 

To enable management of the CCITT No. 7 
signalling network to be exercised, messages 
are exchanged between the various SNM 
functional blocks in the signalling points 
within the network. The messages are handled 
by the MTP in a manner similar to user part 
generated messages with the exception that 
message routing will ensure that certain mess- 








PARAMETER 
(NOT ALWAYS 
PRESENT) 

HEADING 

CODE 

HI 

HEADING 

CODE 

HO 

SLC 

OPC 

DPC 

LENGTH 8/16 

4 

4 

4 

14 

14 


(bit) First bit 

transmitted 

DPC: Destination point code 
OPC: Originating point code 
SLC: Signalling link code 


ages are sent/not sent over specific signalling 
links. The format of a signalling network 
management message is shown in Figure 10, 
the coding of messages in Table 1, and the 
list of parameters in Table 2. 

Signalling Link Test 

In addition to signalling network management 
messages, the MTP also contains a procedure 
for validating signalling links. This procedure 
makes use of the signalling link test (SLT) 
signal which is applied to aligned and proved 
signalling links. Only when the test has been 
successfully completed by the SLT and cor¬ 
rectly acknowledged is the link marked avail¬ 
able for use and signalling traffic allowed onto 
the link. The SLT is differentiated from other 
test and management messages by having a 
different service indicator code in the SIO. 

BT VERSION OF CCITT No. 7 MTP 

The version of the MTP specified for CCITT 
No. 7 (BT) signalling aligns very closely with 
that of the CCITT Recommendations 
Q.701-704, Q.706 and Q.707. However, since 
the implementation of CCITT No. 7 signal¬ 
ling in the BT network is in advance of the 
majority of other national operators in the 
world, and is probably the largest in link/ 
route/signalling point terms, operational 
problems have been encountered which the 
CCITT Red Book does not yet consider. In 
addition to departures to take account of those 
identified operational considerations, the 
MTP required is also dictated by the structure 
of the network, the services to be provided for 
the customers and the multi-operator environ¬ 
ment that exists in the UK. 

The main areas in which the MTP for 
CCITT No. 7 (BT) signalling departs from 
the current CCITT Recommendations are: 
compatibility, circular routing, congestion 
procedures, performance, and the procedures 
necessary to enable secure operation in a 
multi-PTO (public telecommunications oper¬ 
ator) network. These departures are specified 
in British Telecom Network Requirement 
(BTNR 146) and are described briefly below. 

Compatibility 

As a consequence of the rate at which CCITT 
No. 7(BT) signalling is being introduced into 
the BT network, and of the rapid changes 
taking place in CCITT No. 7 signalling devel¬ 
opment, there will inevitably be a number of 
versions of CCITT No. 7(BT) signalling in 
the BT network at the same time. To achieve 
successful interworking between exchanges of 
different versions in the BT network, compati¬ 
bility mechanisms are specified. These include 
the reception and treatment of messages that 
are not understood, a limitation on the sending 
of messages which are not answered, and an 
indication of the level of implementation when 
a message is not understood. 
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TABLE 1 

Heading Code Allocation of Signalling Network Management Messages 


Message 

Group 

\hi 

H0\ 

0000 

0001 

0010 

0011 

0100 

0101 

0110 

0111 

1000 

1001 

1010 

1011 

1100 

1101 

1110 

1111 


0000 

















CHM 

0001 


coo 

COA 



CBD 

CBA 










ECM 

0010 


ECO 

ECA 














FCM 

0011 


RCT* 

TFC 














TFM 

0100 


TFP 


TFR* 


TFA 











RSM 

0101 


RST 

RST* 














MIM 

0110 


LIN 

LUN 

LIA 

LUA 

LID 

LFU 











0111 

















DLM 

1000 


DLC 

CSS 

CNS 

CNP 













1001 


















1010 


















1011 


















1100 


















1101 


















1110 


















1111 


















CBA changeover acknowledgement signal 

CBD changeback declaration signal 

CHM changeover and changeback messages 

CNP connection not possible signal 

CNS connection not successful signal 

COA changeover acknowledgement signal 

COO changeover order signal 

CSS connection successful signal 

DLC signalling data link connection order signal 

DLM signalling data link connection order message 

ECA emergency changeover acknowledgement signal 

ECM emergency changeover message 

ECO emergency changeover order signal 

FCM signalling traffic flow control messages 

RCT signalling route set congestion test message* 


RSM signalling route test message 

RST signalling route set test signal 

TFR transfer restricted signal* 

TFA transfer allowed signal 

TFC transfer controlled message 

TFM transfer prohibited/transfer allowed/ 

transfer restricted messages 
TFP transfer prohibited signal 

MIM management inhibit messages 

LID link inhibit denied signal 

LFU link forced uninhibit signal 

LIN link inhibit signal 

LIA link inhibit acknowledgement signal 

LUA link uninhibited acknowledgement signal 

LUN link uninhibited signal 


National only options (second RST tests TFR) 


TABLE 2 

Signalling Network Management Message Parameters 


Message 

Parameter 

Parameter Coding 

Changeover 

FSN of last accepted MSU 

Bits A-G = FSN, bit H spare 

Changeback 

Changeback code 

Bits A-H determined by SP 

Transfer prohibited 

Destination 

Bits A-H first octet + A-F second octet as for 
destination point code, GH spare 

Transfer allowed 

Destination 

As for destination point code, GH spare 

Signalling route set test 

Destination 

As for destination point code, GH spare 

Transfer controlled 

Destination 

As for TFA, TFP + GH = congestion 

Transfer restricted 

Destination 

As for TFA and TFP 


Circular Routing 

The MTP feature which allows dynamic re¬ 
routing to overcome network failures can also 
create a problem. This can occur when two or 
more diversions take place which result in a 
closed loop being formed in the signalling 


network around which messages circulate. 
Hence no replies would be received by the 
node originating the message. This phenom¬ 
enon, known as circular routing , although 
rare, cannot be allowed in the network, and 
mechanisms to prevent the multiple re-rout- 
ings which lead to circular routing are built 
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into the BT version of the CCITT No. 7 
signalling MTP. 

Performance 

MTP performance is specified in CCITT Rec¬ 
ommendations and allows for a message loss 
of 1 in 10 7 , an error rate of 1 in 10 10 , out-of- 
sequence messages 1 in 10 10 , STP transfer of 
20 X 10 _3 s, and a route availability of 1 in 
1-9X10 5 (or 10 minutes per year). In 
addition, BT requirements specify timer 
values (in line with the latest CCITT pro¬ 
posals), signalling traffic throughput, and 
message transfer times. 

Operational Requirements 

BT’s experience in operating the MTP in 
a network environment has resulted in load 
sharing requirements for multi-link link-sets 
being identified and specified. In addition, 
BT supports other facilities in its network to 
provide customer services, such as operator 
assistance. These additional MTP users need 
to be recognised and therefore supported by 
the MTP. 

Multi-Operator Working 

To ensure that signalling interchanges 
between BT and other PTOs are in line with 
interconnect agreements, special mechanisms 
are required in the MTP to allow only agreed 
signalling messages on the interconnect 
routes. 

Activity in CCITT 

With the considerable experience gained in 
both implementing and operating CCITT 
No. 7 signalling in the national network and 
through British Telecom International being 
one of the first operators to introduce CCITT 
No. 7 signalling into the international net¬ 
work, BT has been one of the leading contribu¬ 
tors to the current discussion in the CCITT 
on the signalling system. The purpose of these 
discussions at both CCITT and in other inter¬ 
national fora has been to update the existing 
recommendations for CCITT No. 7 signal¬ 
ling. The enhanced recommendation will be 
contained in the Blue Book (CCITT Rec¬ 
ommendations 1985-1988), which will incor¬ 
porate many modifications resulting from 
experience in operating CCITT No. 7 signal¬ 
ling based on inputs from BT. It is hoped that 
it may soon be possible to limit work on the 
MTP purely to these modifications required 
for operational purposes. The resulting 
CCITT recommendation should then be a 
stable document that is very closely aligned 
with the CCITT No. 7(BT) signalling MTP. 

EVOLUTION OF MTP 

Although it is BT’s general aim to stabilise 
the MTP requirements, the following items 
need to be considered before the CCITT 


No. 7(BT) signalling system can be regarded 
as complete: 

User Part Availability/ Unavailability/ 
Congestion 

At present, CCITT No. 7(BT) signalling 
MTP has only one user — the NUP. However, 
as outlined in the earlier article[l] in this 
series, multiple use of the MTP is likely from 
early-1990. With the advent of multiple MTP 
users at BT nodes, it is desirable to have a 
mechanism to indicate to an originating MTP 
user, the availability, unavailability, or con¬ 
gestion level of a similar MTP user at a remote 
node. This would permit an indication to be 
given to an originating signalling connection 
control part (SCCP) say, when the destination 
SCCP was congested, but before the desti¬ 
nation point code as a whole was indicated as 
congested. Thus interference with other MTP 
users at the originating node, for example, 
NUP, would be avoided. A UK contribution 
on a suitable mechanism is currently being 
considered by CCITT. 

Test Process User Part 

In order to test the MTP of CCITT No. 7 
signalling, during both system development 
and in service maintenance activities, special 
facilities are needed. Many of these test facili¬ 
ties may be provided by the operations and 
maintenance application part (OMAP), but 
OMAP cannot be used until full network 
provision of the SCCP is realised. A major 
need is for a means of generating simulated 
signalling traffic to be carried by the MTP 
during testing. There is also a need for the 
provision of test and maintenance traffic to be 
carried by an inhibited link. Thus a require¬ 
ment for a suitable test process user part 
(TPUP) exists, at least in the medium term. 

The latest BT thoughts on TPUP require 
only a few nodes to be provided with the full 
testing mechanism, but do require the MTP to 
have the capability of ‘turning round’ received 
TPUP messages. Draft documentation for this 
capability has been prepared. 

272 Octet SIF Capability 

At present, CCITT No. 7(BT) signalling 
MTP has the capability of sending up to 62 
octets of user data in messages. This capability 
will need to be extended to the CCITT agreed 
maximum value of 272 octets when certain 
supplementary services are supported by the 
SCCP. Segmentation and re-assembly of 
messages are not MTP functions. 

Compatibility 

The compatibility mechanisms outlined above 
may not be suitable for long-term use if the 
MTP is to be evolved in the future. Enhance¬ 
ment of the these basic mechanisms may 
therefore be required. 
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CCITT Signalling System No. 7: National User Part 

D. C. MITCHELL, and B. E. COLLAR! 

UDC 621.395.34 

This article is the third in the series of articles on CCITT Signalling System No. 7 and its application 
to the British Telecom network. It considers the national user part with relation to the support of 
the necessary protocols to set-up, monitor and clear down circuit-switched telephony and ISDN 
connections for basic and supplementary services within the public switched telephony network and 
ISDN environments. The message set and message contents needed to support these protocols are 
included along with typical message sequence charts indicating call set-up and release. The 
relationship with, and differences from, the internationally specified telephone user parts are also 
discussed. 


INTRODUCTION 

The transfer of call-control information 
between modern processor-controlled exch¬ 
anges in an enhanced telecommunications net¬ 
work requires a fast, reliable and concentrated 
signalling system servicing many transmission 
paths in a digital transmission environment. 

Other articles[l, 2] give an overview on 
how this has been achieved by the use of 
the CCITT No. 7 common-channel signalling 
system which has been adapted for use to 
support the national requirements of the Bri¬ 
tish Telecom network. A further article[3] 
describes how this secure method of transfer¬ 
ring messages is achieved by the message 
transfer part (MTP) of CCITT No. 7 signal¬ 
ling, which is based on a layered structure 
covering Levels 1, 2 and 3 of the signalling 
system specification. 

The national user part (NUP) of CCITT 
No. 7 signalling, known as Level 4 in the lay¬ 
ered structure of the signalling system, is 
application dependent and includes the mess¬ 
ages, message codings and protocols necessary 
to support basic telephony and ISDN call 
control. The NUP is also required to support 
an ever increasing number of supplementary 
services for both telephony and ISDN cus¬ 
tomers, either exclusively or in conjunction 
with the signalling connection control part 
(SCCP)[4] and its associated transaction 
capabilities^], which are described in further 
articles in this series. 

The protocols developed for the NUP are 
of an interactive nature which allow efficient 
use of the signalling system in a fully-digital 
environment, but provide for optimum post¬ 
sending delays when interworking with the 
non-CCITT No. 7-signalling public switched 
telephone network (PSTN). This is considered 
an important aspect since it will be a number 
of years before the BT network will be 
enhanced to full CCITT No. 7 signalling. 

Because of the evolving nature of the net- 

t CCITT No. 7 Standards Group, British Telecom 
UK Communications 


work and the need to introduce new facilities 
and services, the NUP is currently under 
continual enhancement. Periodically, new ver¬ 
sions of the NUP requirements are published 
to support further packages of network and 
customer services, including the backwards- 
compatibility aspects necessary to allow inter¬ 
working with earlier versions of the NUP. 

Version 1 of CCITT No. 7(BT) was speci¬ 
fied^], in 1983, in conjunction with the 
System X family of exchanges. Version 1 
offered basic telephony service, the facilities 
to support the operator services subsystem 
(OSSBT) and support of the initial ISDN 
service based on the Digital Access Signalling 
System No. 1 [7] (DASS 1). DASS is the 
customer-to-exchange signalling system. 

Work continued to produce version 2[8] 
of the CCITT No. 7(BT) signalling system 
leading to its publication in 1985. Version 2 
included additional features for the ISDN 
services, the support of the Digital Access 
Signalling System No. 2[9,10] (DASS 2) and 
the ability to interwork with version 1 of 
CCITT No. 7(BT) and DASS 1. 

In July 1987, the specification work was 
completed for the version 3 [11] of CCITT 
No. 7(BT) signalling and was followed by the 
competitive tendering exercise for the main 
network for the supply of System X and 
AXE 10 digital exchange equipment. British 
Telecom’s digital derived services network 
(DDSN) was also involved in the version 3 
tendering exercise for the 5ESS digital switch 
to enhance its overlay network. Version 3 pro¬ 
vides for additional network and supplemen¬ 
tary services as well as the ability to interwork 
with both version 1 and version 2. Both 
DASS 1 and DASS 2 are supported by ver¬ 
sion 3. 

A brief resume of the penetration of the 
NUP versions provided in the network is given 
below, but due to the continuing programme 
of updating exchanges, the figures given 
should only be considered as approximate. 

There are 49 main and 500 local System X 
exchanges in service at version 1. With the 


British Telecommunications Engineering , Vol. 7, April 1988 


19 




provision of CCITT No. 7(BT), version 1, in 
TXE4E exchanges, enhanced signalling capa¬ 
bilities were provided to approximately 
250-500 exchanges of the analogue network. 
This enhancement to the analogue network 
gives the advantages to the customer of a 
message-based signalling system; that is, 
shorter call set-up times. 

There are six main and three local 
System X exchanges at version 2, but this will 
increase as the programme of enhancement 
updates all version 1 exchanges to version 2 
by the end of 1988. Approximately 10-20 
AXE 10 exchanges and all nine 5 ESS exch¬ 
anges of the DDSN (Freephone and premium 
rate services) supplied by APT are at ver¬ 
sion 2. 

All implementations of version 3 have an 
expected in-service date by the end of 1989 
to early-1990. 

Each implementation does not necessarily 
conform to the complete specification of 
CCITT No. 7(BT), at each version, but uses 
a sub-set of the basic specification whilst 
ensuring that they interwork with all the other 
implementations. 

At present, the other users of CCITT 
No. 7(BT) are Mercury Communications 
Ltd, Racal Vodafone, Telecom Securicor 
Cellular Radio, Eire, Kingston Communi¬ 
cations (Hull) pic, Manx Telecom, Jersey 
and Guernsey. As their requirements differ 
slightly from British Telecom, they do not 
necessarily implement the complete CCITT 
No. 7(BT) but use a sub-set, whilst ensuring 
that they interwork between themselves and 
the BT network. 

CCITT No. 7(BT) BASIC SERVICES 

Below is a description of the basic services 
and a list of the supplementary services sup¬ 
ported by version 3 of the NUP. A description 
of each the supplementary services is given 
later in this article. 

ISDN Telephony 

DASS 1 and DASS 2 ISDN terminals have 
the capability to originate normal telephony 
calls when suitable voice telephone equipment 
is connected at the terminal or the call is to 
a non-ISDN customer. 

DASS 1 ISDN Digital Call 

(a) ISDN Digital Voice/Data Call This 
is where a voice call is connected over a 
general digital path and, by mutual consent, 
the users can transmit data over this path. 

( b) ISDN Digital Data Path This is pro¬ 
vided to transmit data only between users if 
the terminals at either end are compatible, a 
voice connection is not available for this type 
of call. 

DASS 2 Calls other then Telephony 

(a) ISDN Category 1 (Data) Calls This 


is defined as a call between two ISDN ter¬ 
minals where a 64 kbit/s non-interruptable 
digital path is mandatory and is available for 
data. If analogue interworking is encountered, 
the call will fail and an appropriate indication 
sent to the calling customer. Under normal 
circumstances this would only occur if the 
calling party inadvertently attempted to set 
up a category 1 call to a non-ISDN line. 

(b) ISDN Category 2 (Voice) Calls This 
is defined as a call from an ISDN terminal to 
a customer, who may or may not have an 
ISDN terminal, where an all digital path is 
preferred, but is not essential. Where the call 
terminates on an ISDN terminal and uses a 
digital path, full digital facilities are made 
available. If analogue interworking is encoun¬ 
tered, the call reverts to telephony and an 
appropriate indication is sent to the calling 
customer. 

Supplementary Services (Supported by 
Version 3) 

User-to-user data 
Closed user group 
Calling/called line identity (CLI) 

Network address extension 

Diversion services 

Selective barring of incoming calls 

Distinctive ringing 

Malicious call identification (MCI) 

Operator priority access 

3-1 kHz call 

Swap 

Network Supplementary Services (Sup¬ 
ported by Version 3) 

Record CLI off given routes 
Call dropback 
Service marks for OSSBT 
Restart using circuit group reset 
Circuit group blocking/unblocking 
Nodal end-to-end data transfer 

MESSAGE FORMATS 

All the messages used between the message 
transfer part (MTP) and the national user 
part (NUP) are based on a standard format 
called a message signalling unit , which con¬ 
forms to the formatting principles of the 
CCITT No. 7 telephone user part messages. 
Figure 1 shows the format of the message 
presented to or received from the message 
transfer part of CCITT No. 7(BT) signalling. 

The top half of the diagram represents the 
message as transmitted to or received from 
the signalling link of the MTP. The lower 
half represents the message as transmitted or 
received by the NUP to/from the MTP. 

Standard Telephony Label 

The standard telephony label comprises 40 
bits, and contains the originating and the 
destination point codes and the circuit identity 
code (CIC). 
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used in Version 3 of CCITT No. 7(BT) signal¬ 
ling. 

As indicated in Figure 2, there are eight 
groups of messages, the first four of which are 
used to set up a basic telephony call. The next 
group of messages deals with the supervisory 
phase of the call. There is an additional group 
to deal with the circuit supervisory functions* • 
The last group of messages is used to invoke 
ISDN services and to pass additional call 
information across the network between the 
originating and the terminating nodes. 

MESSAGE SEQUENCES 
Basic Telephony Call 

Figure 3 shows the message sequence, toge¬ 
ther with a brief description of the messages 
used, for a non-ISDN call routed over unidi¬ 
rectional circuits. The call is routed by the 
local switching unit (LSU) to a digital main 
switching unit (DMSU-A). DMSU-A routes 
the call to the destination LSU via a second 
DMSU (DMSU-B), which requests 
additional dialling information. A call within 
the BT network would normally route via one 
or a maximum of two DMSUs. 

A more detailed description of the contents 
and coding of the messages in this sequence 
is given in Appendix 1 of this article. 

ISDN Call 

Figure 4 shows the message sequence for an 
ISDN category 1 call, routed (via a DMSU 
in this example) over bi-directional circuits. 
For an ISDN call, the complete destination 
address is contained in the DASS 2 initial 
service request message (ISRM). 

A more detailed description of the contents 
and coding of the messages in this sequence 
is given in Appendix 1 of this article. 

SUPPLEMENTARY SERVICES SUP¬ 
PORTED BY THE NUP 

User-to-User Data 

This service is invoked by negotiation during 
the call set-up and provides a means of trans¬ 
mitting data between two users. The data 
is transferred across the signalling network 
transparently. This is restricted by the use of 
flow control in the node to prevent the signal¬ 
ling network becoming overloaded with this 
type of message. 

Closed User Group 

This facility enables a group of users to inter¬ 
communicate only among themselves via the 
public network. One or more users may be 
provided with incoming/outgoing access to 
users outside the group. 

Calling/Called Line Identity 

Calling and called line identification (CLI) is 
supported automatically for ISDN category 1 
and category 2 calls by an exchange of service 


Note 1: At the local switching unit (LSU), the customer's off 
hook condition is recognised and some form of digit reception 
device is connected to the customer's line circuit. As soon as 
the calling party has dialled sufficient digits for the LSU to 
select an outgoing route/circuit, the LSU sends an initial address 
message (1AM) on the route selected to DMSU-A. This message 
contains information that enables DMSU-A to route the call; 
that is, calling party category, dialled digits and any special 
requirements for the call path. DMSU-A, after route/circuit 
selection, sends an 1AM to the destination DMSU (DMSU-B). 

Note 2: On inspection of the dialled digits, DMSU-B determines 
that additional digits are required to complete the call. DMSU- 
B sends to DMSU-A a send N digits message, N being the 
number of digits required. DMSU-A then sends the message to 
the calling party's LSU. 

Note 3: When the required number of digits has been received 
from the customer, a subsequent address message (SAM) is 
sent to DMSU-B, via DMSU-A, containing the required digits. 
On reaching DMSU-B, which now has all the digits required, an 
initial and final address message (IFAM) is sent to the called 
party's LSU. The IFAM contains all the dialled digits, the calling 
customer's calling party category and any special call path 
routing requirements. 

Note 4: On receipt of the IFAM, the called customer's LSU 
determines the state of line termination and, if free, sends an 
address complete message (ACM) to the calling party's LSU 
via the two DMSUs. The ACM is used to inform the originating 
LSU whether any interworking with a non-CCITT No. 7(BT) has 
occurred. When the ACM is received at the calling customer's 
LSU, the transmission path is connected; the ring tone con¬ 
nected at the called customer's LSU is heard by the calling 
customer and ringing current is applied to the called customer. 

Note 5: When the called customer answers, the off hook 
condition is detected at the LSU and an answer (charge) 
message is sent, via the DMSUs, to initiate charging at the 
calling customer's LSU. There is no more involvement of the 
CCITT No. 7(BT) signalling system until either party goes on 
hook. 

Note 6: There are two possible options here, either the called 
or calling customer is first to go ON hook: 

(a) If the called customer goes on hook first, a clear message 
is sent by its LSU to the calling customer's LSU, the executive 
point for the call, where a called-subscriber-held timer is started. 
Either on the maturity of this timer or if the calling party goes 
on hook, a release (reason) message is forwarded to the called 
customer's LSU; the reason in this case would be subscriber 
call termination. As soon as this release (reason) message is 
received by each node, it responds with a circuit free message 
to indicate that the circuit is now free and available for selection. 

[b) If the calling customer goes ON hook first (not shown 
in the figure), the release (reason) message would be sent 
immediately to the called customer's LSU. The action at each 
node would be to release the call and send a circuit free 
message to the preceding node. 


Figure 3—Message sequence 
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Point Codes 

Every node using CCITT No. 7(BT) has at 
least one unique point code. The destination 
point code (DPC) is used by the MTP to 
route the message to the correct node. The 
originating point code (OPC) is used by the 
receiving node to direct any replies to the 
correct node. Thus, for each NUP message, 
the destination point code and originating 
point code identifies the traffic route to which 
the message relates. 

Circuit Identity Code 

The circuit identity code uniquely identifies 
the particular circuit within the identified 
traffic route to which the signalling infor¬ 
mation contained in the message relates. It is 
important to remember that any node which 
performs a switching function between 
Figure 2 CCITT No. 7 signalling circuits will also per- 

Allocation of HO/HI f° rm a label translation for every NUP 
codes message relating to that call because different 


routes and circuits are involved in the switched 
connection. 

Message Header 

The message header is divided into two fields: 
HO to indicate the group of messages, and HI 
to indicate the actual message within that 
group. For some messages, no additional fields 
are required, but other messages, of a more 
complex nature, contain additional infor¬ 
mation in mandatory and/or optional fields. 

Mandatory Fields 

Mandatory fields are always present in a par¬ 
ticular message type in a specified order, and 
may be of fixed or variable length. The vari¬ 
able-length fields contain information of 
varying length such as dialled-digit infor¬ 
mation. For each variable-length field there 
must be an immediately preceding fixed- 
length field that indicates the length of the 
variable field concerned. 

Optional Fields 

Certain messages may contain optional fields, 
which can be of fixed or variable length. These 
fields are usually associated with messages 
that provide additional information (if avail¬ 
able) about the call. These messages must 
contain a mandatory field indicating which 
optional fields are present in the message. For 
a particular message type, optional fields, if 
present, are always included in a particular 
order. For each variable-length field there 
must be an immediately preceding fixed- 
length field to indicate the length of the vari¬ 
able field concerned. 

Header Fields 

As mentioned above, the header is divided 
into two fields, HO/HI. Figure 2 shows the 
HO/HI combinations for each of the messages 
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* Allocated for intra-exchange use only () Reserved for non-BT use HO Codes 8-255 spare HI Codes 17-255 spare 
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Note 1: On receipt of the ISRM, the calling customer's LSU sends an IFAM with the service handling protocol (SHP) set to 
inform the destination LSU that this is an ISDN call and therefore ISDN protocol should be used; and the call path indicator 
(CPI) set to indicate, to each intermediate node, that a 64 kbit/s path with CCITT No. 7(BT) signalling is mandatory for this 
call. 

The intermediate DMSU, on receipt of the IFAM, sends an IFAM to the called customer's LSU after route/circuit selection. 
Neither the SHIP nor the CPI values are altered by the intermediate DMSU. 


Note 2: The called customer's LSU, on receipt of the IFAM with the SHP of 1, sends a DASS 2 channel seized message to 
the called customer and invokes an ISDN service information message (SIM) interchange with the calling customer's LSU. 
These messages are passed from end-to-end without being reprocessed at any intermediate DMSUs, apart from the necessary 
label change. 

The ISDN SIMs are used to pass information between the calling and called party's LSU. It is a three-message protocol 
referred to as the SIM A, SIM B and SIM C interchange. Thirteen types of ISDN SIM are defined to support the current range 
of ISDN services. 

(a) SIM A is passed in the backward direction and typically contains the facility indicator code (FIC) of the called customer 
which indicates whether it supports closed user group (CUG), user-to-user data etc. It can also request the called customer's 
FIC, calling line identity (CLI) etc. 

( b) SIM B is passed in the forward direction and typically contains the calling customer's FIC, CLI, service indicator code 
(supplied by the terminal via DASS 2), CUG interlock code etc. It can also request the called customer's CLI and FIC. 

(c) SIM C is passed in the backward direction and typically contains the called customer's CLI and FIC. As it is the last 
message of the interchange, the SIM C does not request any information. 


Note 3: The calling customer's LSU returns the requested information in a SIM B on receipt of the SIM A from the called 
customer's LSU. On receipt of the SIM B, an incoming call indication is sent via DASS 2 to the called customer. 


Note 4: If the called customer's equipment accepts the call, then the ISDN SIM C is returned to the calling customer's LSU. 
In addition, the call arrival indication is sent to the called customer and the address complete message is sent to the calling 
customer's LSU, via the DMSU, where it is mapped to the DASS 2 message number acknowledge. The address complete 
message contains an interworking indicator, and in this case it is set to indicate that a fully digital path is available with CCITT 
No. 7(BT) signalling used throughout. 


Note 5: On receipt of the call connected (DASS 2) message from the calling customer the answer (charge) message is sent 
to the calling customer's LSU and on to the calling customer in the call connected (DASS 2) message. At this stage a 
transparent digital path is provided. During a call, CCITT No. 7(BT) can also provide an additional two-way user-to-user data 
path via the signalling network. The rate at which the messages are transmitted is restricted by flow control at the outgoing 
LSU to prevent overloading of the signalling network. 


Note 6: During this transfer of data, either customer can initiate swapping the call to speech, if supported by both terminals, 
by using the swap message. The call can then be swapped back to data again by using the swap message, with no restriction 
on the number of times that a call is swapped. 


Note 7: At the end of the call, there are two possible options: either the calling or called customer is first to request the 
connection to be cleared. 

(a) Assuming that the calling customer clears first, then the clear request is sent to the LSU via DASS 2. The calling 
customer's LSU then sends the release (reason) message to the next node, which responds with a release (reason) and circuit 
free message. On receipt of the release (reason) message, the calling customer's LSU responds with a circuit free message. 
This interchange is due to the circuit being bi-directional and so both ends of the circuit need to know its state. This is 
repeated over the successive links until the called customer's LSU is reached; then the clear indication (DASS 2) message is 
sent to the called customer. 

( b) If the called customer is the first to request clearing of the call (not shown in the figure), then a clear message is 
returned to the calling customer's LSU, similar to the non-ISDN call, but in this case the CSH timer is set to 0. Hence the 
response is an immediate release (reason) from the calling customer's LSU. 
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Figure 4—Message sequence for an ISDN category 1 call 
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information messages at call set-up. Where 
possible, all calls, including non-ISDN calls, 
have the calling line identity included in the 
initial address message/ initial and final 
address message (IAM/IFAM) to allow dis¬ 
play at the called ISDN terminal if the cus¬ 
tomer subscribes to the CLI presentation ser¬ 
vice. 

Both the calling and called line identities 
are available for network and other sup¬ 
plementary use, even if not provided in the 
IAM/IFAM, by the use of end-to-end request 
and response messages. If analogue inter¬ 
working is encountered then the partial calling 
line identity, giving incoming route and circuit 
information, etc., from the interworking node, 
is provided by means of link-by-link messages. 

Network Address Extension 

This service is invoked by negotiation during 
the call set-up. Extended address information, 
for ISDN categories 1 and 2 (full digital path 
only) calls, is carried across the public network 
from the calling party to the called party. This 
extended address information consists of up 
to six alphanumeric characters and is used to 
select a destination beyond that indicated by 
the called national number. 

Diversion Services 

At present, the diversion service is available 
for telephony calls and category 2 calls. How¬ 
ever, category 2 calls are reverted to telephony 
when diversion is active. The diverted leg of 
the call is treated by the CCITT No. 7(BT) 
as a separate call, but the calling line identity 
contained in the IFAM is the originating 
customer’s number. An indicator is set to 
inform the terminating customer that this is 
a diverted call, to allow the called customer 
the option of requesting the diverting cus¬ 
tomer’s calling line identity. 

Selective Barring of Incoming Calls 

This service requires all incoming calls to the 
subscribing customer to provide the calling 
line identity to allow the terminating node 
to selectively bar/accept calls from specific 
calling customers. 

Distinctive Ringing 

This service requires all incoming calls, to the 
subscribing customer, to provide the calling 
line identity to allow the terminating node to 
apply distinctive ringing to the called cus¬ 
tomer, dependent on the origin of the call. 

Operator Priority Access 

This service allows the operator to mark a call 
as priority access. This enables the call to 
have priority over non-priority calls and, in 
extreme circumstances, may cause non-pri¬ 
ority calls to be released if no free circuits are 
available for the priority call. 


Malicious Call Identification 

Network support of this service is achieved by 
invoking last party release, in the address 
complete message, on all incoming calls to the 
customer concerned. If possible, the calling 
line identity of each incoming call is stored 
until the call is released so that if, during a 
call, an MCI indication is received from the 
called customer, the CLI is printed out and 
the call held in the backward direction. 

31 kHz Call 

A call marked as a 3 • 1 kHz call requires a 
specific transmission path for certain ISDN 
and data services. This marking ensures that 
the call is not routed via any speech processing 
equipment, such as, adaptive-differential 
pulse-code modulation (ADPCM), in the 
international network. 

Swap 

This is the DASS 2 facility to allow either 
user in an ISDN category 1 or category 2 call 
to change from voice to data mode or from 
one data mode to another whilst in the 
answered state. 

NETWORK SUPPLEMENTARY SER¬ 
VICES 

Record CLI Off Given Routes 

To support this requirement, the network is 
required to provide the calling line identity 
for all calls on a given route. The calling line 
identity is available for network use either in 
the IAM/IFAM or by the use of end-to-end 
or link-by-link request and response messages. 

Call Dropback 

This facility was provided for a call re-routed 
by the digital derived services network to a 
number in the PSTN. It is used to release the 
original call path until a node is reached where 
it is most economical to route to the new 
PSTN number. 

Service Marks for OSSBT 

To provide the OSSBT operator with 
additional information concerning incoming 
or outgoing calls, service marks are requested 
from the originating or terminating node by 
means of a service request/response inter¬ 
change of messages. 

Restart 

After exchange failure, the call states of some 
of the circuits could be affected by memory 
mutilation. This procedure provides a method 
of resetting only the circuits that are affected 
by such a memory loss. 

Group Blocking/Unblocking 

This provides a method of blocking a group 
of circuits as a consequence of either fault 
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situations or manual maintenance inter¬ 
vention. Group blocking/unblocking pro¬ 
cedures prevent the signalling system from 
being overloaded by avoiding the sending of 
multiple single circuit blocking/unblocking 
messages. 

Nodal End-to-End Data Transfer 

This is at present used for the virtual private 
network (VPN) and business exchange ser¬ 
vices (BES) to enable the VPN/BES mess¬ 
ages to be transparently passed across the 
public network. 

TELEPHONE USER PART (TUP) 

In the late-1970s, the CCITT forum was 
actively involved with the specification of the 
telephone user part (TUP) for the Yellow 
Book [12] Recommendations Q.721-Q.725 
published in 1980. At this time, inter¬ 
nationally, both the ISDN and supplementary 
services where not fully defined; therefore, the 
Yellow Book TUP did not support either the 
supplementary services or the ISDN facilities 
that British Telecom required. The TUP only 
supported the required messages and their 
respective formats and codes to provide basic 
telephony services based on earlier inter¬ 
national signalling systems for use between 
international switching units. Further exam¬ 
ples of the limitations of the TUP are listed 
below to illustrate the reasons why British 
Telecom found it necessary to specify a 
national user part which differed considerably 
from the CCITT specification available at the 
time: 

$ A restriction on the TUP, as far as British 
Telecom was concerned, was that the TUP 
could only support a total of 256 messages in 
16 different groups so that future expansion 
of the number of messages was limited. British 
Telecom increased the size of the message 
header code to enable the NUP to support 
65536 messages in 256 different groups to 
provide a greater degree of expansion. 

• To support an ISDN capability, there was 
a need to provide nodal end-to-end signalling 
in addition to the link-by-link signalling pro¬ 
vided in the TUP; that is, the service infor¬ 
mation message (SIM) interchange in the 
NUP to support ISDN call set-up. Also, an 
ISDN call requires the circuit to be released 
by the first customer to clear, a facility not 
offered by the TUP. 

• British Telecom required a more flexible 
approach to charging than the TUP offered. 
m The TUP did not support the special facili¬ 
ties required for calls to, from and between 
the operator services subsystem (OSSBT) that 
British Telecom required. 

• In the TUP, there is no version indicator 
or compatibility mechanism. This meant that 
both ends of a circuit would have to conform 
to the same version of TUP; that is, Yellow 
Book. 


$ The TUP was specified to cover both 
national and international use, but did not 
support the interactive signalling protocols 
considered essential in the BT network to 
make optimum use of the signalling network 
in both full CCITT No. 7 and analogue inter¬ 
working situations. 

# An item that was included in the TUP that 
was not considered necessary for the NUP 
was the continuity check of the speech path 
for use when CCITT No. 7 controls analogue 
circuits. As British Telecom only intends to 
use CCITT No. 7 signalling on digital routes, 
which have inbuilt error checking of the trans¬ 
mission path, this facility was not required in 
the NUP. 

$ When the CCITT Red Book was published 
in 1984[13], the TUP contained some sup¬ 
plementary services, but there was still not a 
complete and stable capability to support the 
full ISDN requirements. The Red Book also 
contained a separate basic set of Recommen¬ 
dations for a user part specifically to support 
ISDN capabilities known as the integrated 
services digital network user part (ISDN 
UP). However, this was not considered a 
stable Recommendation since certain areas, 
including supplementary services, were indi¬ 
cated as being for further study. A further 
article[14] in this series describes the ISDN 
user part including its enhancement for 
inclusion in the next series of CCITT Rec¬ 
ommendations; that is, the Blue Book. 

• As mentioned above, the TUP does not 
have a version indicator or a compatibility 
mechanism, therefore, the implementations 
that are based on the Yellow Book TUP are 
unable to directly interwork with Red Book 
TUP implementations on a route basis; for 
example, a Red Book TUP may send a 
message that is not recognised in the Yellow 
Book TUP, resulting in call failure. Also, 
a message containing supplementary service 
information sent from a Red Book TUP to a 
Yellow Book TUP may not be recognised. 

The supplementary services that are sup¬ 
ported by the Red Book TUP are: 

Closed user group 

User access to the calling/called line identi¬ 
fication 

Redirection of calls 

Call completion to a busy customer 

Network access to calling line identification 
(malicious call identification) 

Digital connectivity (digital path required 
throughout the call) 

TELEPHONE USER PART+ (TUP+) 

During the mid-1980s, the EEC com¬ 
missioned the Analysis and Forecasting 
Group (GAP) to produce a report on the co¬ 
ordinated introduction of an ISDN in ‘The 
Community’. This recommended a phased 
introduction of an ISDN service in Europe 
with phase 1 to be implemented in the period 
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1988-1993. The result of this was the TUP+ 
specification[15] produced in 1987 by a 
working party of CEPT for use in the inter¬ 
national network to interconnect countries in 
Europe. In addition to ISDN facilities, the 
TUP+ also provides for the following phase 
1 supplementary services: 

Closed user group 
Calling line identification 
Sub-addressing 
User-to-user data transfer 
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APPENDIX 1 

NUP MESSAGE FORMATS AND CODES 

Listed below are some typical examples of 
message formats and codes used by the 
CCITT No. 7(BT) NUP. The examples 
chosen are those used in the call sequences in 
this article. BTNR 167 contains the complete 
list of all the formats and codes used in the 
CCITT No. 7(BT) messages. 

Initial Address Message/ Initial and Final 
Address Message (IAM/IFAM) 

This is the first message generated for any 
call and implies that the circuit identified in 
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the message label has been seized for this call 
attempt. See Figure 5. 

Listed below is typical information that is 
contained in the sub-fields shown in Figure 5, 
more detailed information can be found in 
BTNR 167 Issue 3. 

{a) Calling Party Category Indicates 
what type of customer originated the call; 
that is, ordinary business, ordinary residential, 
ISDN business or ISDN residential etc. 

( b) Originating Node CCITT No. 7(BT) 
User Part Version Indicator Provides an 
indication of the version of the originating 
CCITT No. 7(BT) node for use in ISDN 
diversion services. 

(c) Message Indicators There are eight 
indicators, typically they indicate whether the 
call has originated from an international net¬ 
work, from another country not via an ISC 
(that is, cross border), or whether this call 
involves analogue interworking. 

(d) Service Handling Protocol Indicates 
any special message interchange for this call; 
that is, service information messages for 
ISDN or request service for a call to the 
operator services subsystem. 

(e) Message Indicators There are eight 
indicators, typically they indicate if a pre¬ 
ceding node is Version 3 to determine the 
correct release procedures, and if the call has 
been routed via satellite. 

if) Network Identifier This indicates the 
network that this call originates in or the 
immediately preceding network in the case of 
a multi-network call. 

(g) Routing Control Indicator This indi- 


28 


British Telecommunications Engineering, Vol. 7, April 1988 







































Figure 6 

Subsequent address 
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Figure 7 

Send TV digits message 


cates whether the use of alternative routing 
for this call is allowed. 

( h) Call Path Indicator This indicates 
whether CCITT No. 7(BT) signalling is 
essential for the routing or if it is only pre¬ 
ferred. This indicator is also used to indicate 
a 3-1 kHz call type so that routes with 
ADPCM or other speech processing equip¬ 
ment may be avoided. 

(j) Number of Address Signals A binary 
number indicating the quantity of digits in 
the address field. 

(/) Address Signals The address signals 
are sent in 4 bit BCD. If the message is an 
IFAM, then it is implicit that there are no 
more address signals to follow. 

(m) Calling Line Identity Message 
Indicators These indicate whether the CLI 
can be released to the called customer. 

(n) Number of Calling Line Address 
Digits A binary number indicating the 
amount of digits in the calling line address 
digits. 

(o) Calling Line Address Digits This 
indicates the calling line identity of the calling 
customer. 

Subsequent Address Message 

This message contains additional address 
digits for call routing (see Figure 6). 
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Typical information that is contained in the 
sub-fields is shown below, for more detailed 
information see BTNR 167 Issue 3. 

( b) Number of Address Signals A binary 
number indicating the quantity of digits held 
in the address signals sub-field. 

(d) Address Signals The address signals 
are sent in 4 bit BCD. 

Send N Digits Message 

After examination of the received address 
message(s), this message is used by either an 
intermediate or terminating node to request 
additional digits (see Figure 7). 


Address Complete (Number Received) 
Message 

This message is sent from a terminating or an 
analogue interworking node indicating that 
all address signals required for routing the 
call to the called party have been received 
(see Figure 8). 


Jb )(£) 




HI =0 

HO = 3 


SPARE 

CALLED 

PARTY 

CATEGORY 

ADDRESS 

COMPLETE 

BACKWARD 

SETUP 

INFORMATION 

LABEL 


- < - < - 

(/) (f>) (g)(0(g) ( d) (c) 









SPARE 

ECHO 

SUPP. 

IND 

SPARE 

INTERWORKING 

INDICATIONS 

LAST PARTY 
RELEASE 
INDICATOR 

SPARE 

CHARGE 

INDICATOR 

(RESERVED 

FIELO) 


1114 1 11 


Figure 8 —Address complete message 


Typical information that is contained in the 
sub-fields is shown below, for more detailed 
information see BTNR 167 Issue 3. 

(a) Calling Party Category This indi¬ 
cates what type of customer originated the 
call; that is, ordinary business, ordinary resi¬ 
dential, ISDN business or ISDN residential. 

(c) Charge Indicator This could be used 
to indicate no-charge or charge for this par¬ 
ticular call. Currently, this value is always set 
to charge. 

(e) Last Party Release Indicator Two 
values only are available; namely, normal 
release and last party release. 

(/) Interworking Indicators These are 
used to inform the originating exchange if 
analogue interworking or interworking to an 
earlier version of the software has occurred. 

(h) Echo Suppressor Indicator This 
indicates whether an incoming half echo sup¬ 
pressor has been fitted in the backward trans¬ 
mission path for this call. 

Answer Message 

This message is sent through the network 
when the called party answers and it is used 
to initiate charging (see Figure 9). 
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Typical information that is contained in the 
sub-fields is shown below, for more detailed 
information see BTNR 167 Issue 3. 

(a) Number of digits Requested The 
number requested can be from 1 to 15. 


Figure 9 —Answer message 

Typical information that is contained in the 
sub-fields is shown below, for more detailed 
information see BTNR 167 Issue 3. 
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(a) Type of Answer The type of answer, 
at present, could be either charge or no charge. 
This indication supersedes any conflicting 
charge/no charge indicator received in the 
address complete message. 

ISDN Service Information Message 

There are 13 ISDN SIMs which are used to 
request and carry information between orig¬ 
inating and terminating nodes with no 
interrogation at the intermediate nodes. Two 
types request and carry information in the 
backward direction. Eight types are used to 
request and carry information in the forward 
direction. The final three types are used to 
carry additional information in the backward 
direction. A complete list of the detailed con¬ 
tents of each of the ISDN service information 
messages (see Figure 10) is contained in 
BTNR 167 Issue 3. 
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detailed information can be found in BTNR 
190 (DASS 2). 

(a) Service Indicator Code This indi¬ 
cates the mode to which the initiating terminal 
wishes to swap, and the swap confirmation 
from the receiving terminal. 

User-to-User Data Message 

The user-to-user data message is used to 
support the DASS 2 requirement to trans¬ 
parently transport user data between the 
calling and called party in either direction 
(see Figure 12). 


Figure 11 
Swap message 
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Figure 10—General format of ISDN composite 
service information messages 

Below is a list of typical information carried 
by the SIMs in either direction: 

Calling and called line identity 
Service indicator code (for a complete list 
see BTNR 190 DASS 2) 

Closed user group interlocking code 
Facility indicator code (that is, user-to-user 
data service available) 

Six character network address extension 
(provides the ability to pass additional digits 
from one terminal to another for use by the 
customer) 

Business group identity 

Swap Message 

The swap message (Figure 11) is used to sup¬ 
port the DASS 2 swap facility on ISDN cate¬ 
gory 1 and category 2 calls. The swap facility 
is controlled by the called and calling cus¬ 
tomers and enables them to transfer between 
speech and data, or different data modes, 
whilst remaining in the answered state. 

This message is passed from end-to-end 
without the need for intermediate node 
interrogation. Listed below is typical infor¬ 
mation that is contained in the sub-field, more 



Figure 12 
User-to-user data 
message 


This message is passed between originating 
and terminating nodes without interrogation 
by the intermediate nodes. Listed below is 
typical information that is contained in the 
sub-fields; more detailed information can be 
found in BTNR 167 Issue 3. 

( b) User-to-User Data Octet Count This 
indicates the number of digits contained in 
the user-to-user data sub-field. 

(d) User-to-User Data This sub-field 
contains the actual data as supplied by the 
customer’s terminal. 

Clear Message 

This message is passed in either direction after 
a network terminal has initiated the clear 
procedure; on reaching the executive point, 
the call is released using the appropriate pro¬ 
tocols. 

This message (see Figure 13) does not 
include any additional sub-fields 
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Figure 13 
Clear message 
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Release (Reason) Message 

This message causes release of the complete 
call and connection of suitable tones and/or 
announcements to the calling party on speech 
calls; on data calls, message-based clearing 
reasons will be passed to the ISDN terminal 
equipment. This message can occur at any 
stage of the call (see Figure 14). 


Figure 14 

Release (reason) message 
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Typical information that is contained in the 
sub-fields is shown below, for more detailed 
information see BTNR 167 Issue 3. 

( 0 ) Reason There are a number of 
reasons that could be included in this message; 
such as, number unobtainable, incoming calls 
barred, and customer engaged. 


Circuit Free Message 

This message is sent following the receipt of 
a release message on an incoming or bothway 
circuit after the switch connection has been 
successfully released and the circuit is free to 
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Figure 15 —Circuit free message 


accept a new call (see Figure 15). 

This message does not include any 
additional sub-fields. 
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CCITT Signalling System No. 7 : Signalling Connection 

Control Fart 

P. G. CLARKE, B.sc.(ENG.), C.ENG., M.I.E.R.E., and C. A. WADSWORTH, t.eng., M.i.ELEC.i.E.f 
UDC 621.395.34 

This article describes the operation of that part of CCITT Signalling System No. 7 which provides 
the enhancements necessary to enable signalling networks to support the internodal transfer of data 
and signalling information which is not directly related to the concurrent establishment of switched 
telephony or ISDN connections. 


INTRODUCTION 

An earlier article [1] contained an overview 
of the CCITT Signalling System No. 7. This 
article describes the purpose and functions of 
the signalling connection control part 
(SCCP), and how it interacts with the other 
parts of CCITT No. 7 signalling. 

CCITT Recommendations (Q.711-Q.714) 
for the SCCP were first published in 1984 [2]. 
However, the 1985-1988 Study Period has 
seen further development of the Recommen¬ 
dations, which will be published in the Blue 
Book in 1988/9. In particular, protocol class 4 
has been deleted, and comprehensive manage¬ 
ment procedures have been added. This article 
is based on the SCCP as it is expected to 
appear in the Blue Book. 

It should be noted that, if and when BT 
wishes to introduce an SCCP into its network, 
it is possible that not all of the protocol classes 
and functions specified by CCITT will be 
needed. In addition, some features not cur¬ 
rently specified by CCITT may be required. 

ORIGINS OF THE SCCP 

Consideration of the evolution of telecom¬ 
munications networks over the next decade 
has highlighted the need for a flexible data 
transfer mechanism within and between those 
networks. Particular applications which could 
make use of this mechanism include: 

• interrogation of centralised databases by 
call processors, 

• updating of vehicle location registers in the 
mobile telephone service, 

• remote activation of supplementary ser¬ 
vices, and 

• data transfer between network manage¬ 
ment centres. 

It should be noted that these applications 
do not necessarily involve the establishment 
of a telephone call or circuit-switched trans¬ 
mission path at the same time. Furthermore, 
even where a transmission path is required, 
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there is no reason (in general) why the data 
of the type referred to above should need to 
share any portion of the same routing as the 
transmission path or call to which it relates. 

The limitations of the user part, for 
example, telephony user part (TUP) and 
message transfer part (MTP) configuration in 
this context are as follows: 

• The TUP was developed for the establish¬ 
ment of telephony connections between local 
exchanges. Signalling cannot take place 
between those terminal exchanges without 
using the TUP for the allocation of a speech 
circuit at each exchange (including inter¬ 
mediate exchanges) used to make the connec¬ 
tion. The transfer of messages by this ‘pass- 
along’ method uses processing resources 
inefficiently and introduces additional delay 
into the message transfer process. 

• The scope of the MTP addressing scheme 
(signalling point code plus service indicator 
code)[3] is limited in three respects: 

( 0 ) signalling point codes do not have 
global significance: each point code is relevant 
only within a given national network or within 
the international network interconnecting 
individual national networks; 

( b ) the total number of signalling point 
codes available in a single signalling network 
is limited to 16 384; 

(c) the maximum number of signalling 
point codes that may be allocated to one 
signalling point has been set to four in the BT 
network; 

(d) the range of values of the service indi¬ 
cator code permits distribution of messages to 
only 16 users of the MTP for a single signal¬ 
ling point code. 

• Some applications may require the estab¬ 
lishment of virtual calls or connections, 
similar to those of the packet-switched data 
service. Such a facility cannot be provided by 
the TUP plus MTP combination. 

Concurrently with realisation of the above, 
work was proceeding in various national and 
international fora on the concept of the open 
systems interconnection (OSI) model [4] for 
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the specification of communication protocols. 
Of particular relevance is the network layer 
service, which aligns closely with the data 
communication facilities required for the 
applications listed above. In essence, the OSI 
network layer service was defined in such a 
way that the user of the service would not need 
to be aware of the nature of the underlying 
physical network(s) used to provide communi¬ 
cation in a given instance. 

The SCCP was conceived with the stated 
objective of providing an OSI network layer 
service, using the MTP network as its under¬ 
lying physical network, and providing a stan¬ 
dard OSI network layer primitive interface to 
the users of that network layer service. 

FUNCTIONS OF THE SCCP 

The primary function of the SCCP is to pro¬ 
vide a means for the transfer of messages 
between any two signalling points in the same 
or different (but interconnected) CCITT 
No. 7 networks. To do this, it may transfer 
data in a connectionless mode, establish tem¬ 
porary signalling connections, and/or use per¬ 
manent signalling connections. 

The services provided by the SCCP to its 
users are specified in the form of four protocol 
classes as follows: 

• Class 0—Connectionless, message 
sequence not guaranteed; 

• Class 1—Connectionless, message 
sequence guaranteed; 

• Class 2—Basic connection-oriented with 
message segmentation and reassembly; and 

• Class 3—Connection-oriented with 
message segmentation, reassembly, flow 
control and detection of message loss or 
missequencing. 

Connectionless Data Transfer 

In the connectionless mode of operation, the 
SCCP transfers messages independently of 
each other, and provides no means of corre¬ 
lating one with another, or of verifying the 
ability of the destination user to receive them. 

Inability of the SCCP to deliver a message 
to the destination user may be indicated to 
the originating user by means of a further 
connectionless message. 

This mode of operation applies to protocol 
classes 0 and 1 only. 

Establishment of Temporary Signalling 
Connections 

Some applications, particularly those 
involving the transfer of large amounts of en 
bloc data, require the establishment of virtual, 
or logical, connections. This mode of operation 
benefits both the user and the network because 
it verifies the ability of an intended recipient 
of data to actually receive it at that time, 
thereby ensuring that large amounts of data 
are not launched willy-nilly into a signalling 


network which, through no fault of its own, 
cannot deliver that data. 

The SCCP has the ability to establish and 
release temporary (virtual) signalling connec¬ 
tions under the control of the user. The need 
or otherwise for this connection-oriented type 
of service is indicated to the SCCP by selection 
of the appropriate primitive by the originating 
user. 

This mode of operation applies to protocol 
classes 2 and 3 only. 

A virtual signalling connection set up by 
the SCCP may consist of several 
SCCP-SCCP links in tandem, each of which 
may be in a different CCITT No. 7 network. 
In this case, each SCCP-SCCP link is 
referred to as a connection section , and the 
intermediate SCCPs act as relay points for the 
overall SCCP-SCCP ‘connection’. At each 
relay point, the SCCP performs the task of 
‘association’ of the two concatenated connec¬ 
tion sections, to achieve the required effect of 
an end-to-end connection. 

Permanent Signalling Connections 

The SCCP also has the ability to support 
permanent (virtual) signalling connections, 
similar to the permanent virtual circuits of 
the packet switched service. These are estab¬ 
lished by administrative action. 

This mode of operation applies to protocol 
classes 2 and 3 only. 

Translation 

The SCCP regards all of its users as subsy¬ 
stems , and they are addressed using a subsy¬ 
stem number (SSN). Provision is made for 
translation from an appropriate global title 
(global address) to the signalling point code 
of the destination SCCP plus an SSN to 
identify the destination user. The global title 
may consist of a national telephone (or ISDN) 
number, an international telephone (or 
ISDN) number, a Telex number, a data net¬ 
work terminal number, or a number from 
any other specified scheme. Which numbering 
scheme(s) is/are supported in any particular 
case is determined at the planning stage and 
is a function of the data build of the SCCP. 

Destination Diversity 

One of the applications identified above for 
the SCCP is the communication between the 
call processor at an exchange and a remote 
centralised database. This procedure may be 
used, for example, in the operation of a Free¬ 
phone service, to provide the exchange with a 
translation of the dialled digits; that is, from 
the Freephone number of the required desti¬ 
nation of the call to the actual PSTN address 
of the call destination. 

Centralisation of this translation function 
clearly has benefits in terms of efficiency over 
its provision for all Freephone numbers at 
all exchanges, but because a single database 
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would then be relied upon by all exchanges 
for support of a Freephone service, failure of 
that database would have a catastrophic effect 
on the Freephone service. Consequently, it is 
usual to duplicate the databases in such a way 
that either one of the pair can take over 
completely in the event of failure, or planned 
withdrawal from service, of the other. 

As a consequence of the duplication of 
databases, means must be provided to ensure 
that messages from exchanges always go to 
the database which is in operation at the time. 
One way of achieving this would be for each 
database to broadcast messages to all exch¬ 
anges in the network whenever it takes over 
from another database. However, this could 
flood the network with messages every time 
a small software update is necessary at a 
database. 

The recommended solution to this problem 
is to make use of the translation capabilities 
of the SCCP at one of a smaller number of 
intermediate nodes to provide the translation 
for the final destination of the message. Thus, 
a local exchange would address the message 
initially by global title. The local SCCP would 
provide the appropriate destination point code 
(DPC) for the MTP to route the message to 
an intermediate node; for example, a DMSU. 
The SCCP at that node, having knowledge of 
the availability status of both of the subsy¬ 
stems that could deal with the message, would 
then address the message to the subsystem 
which is actually up and running at that time, 
by providing the appropriate final DPC and 
SSN. 

Message Sequencing 

For some applications, it is necessary that 
messages are delivered to the destination user 
in the same order in which they are received 
by the SCCP at the originating end. The 
SCCP achieves this by assignment of the same 
value to the signalling link selection (SLS) 
code passed to the originating MTP, for all 
messages required to be delivered in the same 
sequence. 

The need or otherwise for this facility in 
any particular instance is indicated to the 
SCCP by the originating user setting an 
appropriate parameter in the primitive used 
to request data transfer. 

In addition, protocol class 3 provides an 
enhanced message sequencing procedure that 
detects message loss and missequencing. 

Message Segmentation and Reassembly 

The CCITT Recommendations for the SCCP 
that will appear in the Blue Book (1988/9) 
are based on a MTP signalling information 
field (SIF) length of 272 octets. Taking into 
account the overheads of the SCCP message, 
this allows a user data field length of approxi¬ 
mately 255 octets in a data message. To 
allow for the transfer of longer messages, 


segmentation and reassembly are specified as 
features of protocol classes 2 and 3. Segmen¬ 
tation and reassembly are not applicable to 
the connectionless protocol classes. 

Message Flow Control 

The SCCP includes message flow control pro¬ 
cedures which are applicable to the flow of 
data messages in protocol class 3 only. The 
purpose of the procedures is to prevent the 
transmission of data on a signalling connec¬ 
tion at a rate greater than that at which 
the receiving end can accept the data. It is 
achieved by setting a limit (the ‘window’) at 
the end originating the data, on the number 
of messages it may send to the same desti¬ 
nation for which acknowledgement has not 
yet been received. The value of the limit is 
negotiated during establishment of the con¬ 
nection. Different window sizes may be 
applied to the two directions of transmission 
on the same connection. 

Expedited Data Transfer 

In addition to message flow control, protocol 
class 3 provides an expedited data-transfer 
facility. This allows the priority transfer of up 
to 32 octets of user data, which by-passes 
the flow-control procedures applied to normal 
data messages. 

Management Procedures 

The SCCP contains management procedures 
whose purpose is to keep track of the 
availability/unavailability status of signalling 
points, of local subsystems (that is, those 
located at the same node as the SCCP), and 
of remote subsystems. The procedures are also 
capable of tracking the congestion status of 
signalling points, and CCITT study is con¬ 
tinuing on the inclusion of mechanisms con¬ 
cerned with subsystem congestion. 

In response to information of the type 
referred to above, the SCCP is able to re¬ 
route traffic to alternative subsystems at the 
same or alternative signalling points. 

The SCCP management procedures also 
allow the controlled withdrawal from service 
of a duplicated subsystem, by redirecting sig¬ 
nalling traffic to its backup subsystem. 

Detailed description of the SCCP manage¬ 
ment procedures is contained in a subsequent 
section of this article. 

ARCHITECTURE AND PRIMITIVES USED 
BY THE SCCP 

General 

Understanding of the operation of the SCCP 
will be greatly enhanced by a thorough 
appreciation of the roles played by messages 
and primitives, and how they are employed in 
conjunction with specified procedures to form 
the signalling protocol. The Glossary at the 
end of this article explains these aspects, along 
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Figure 1 with some clarification of other frequently 

Primitives used by the use d terms. 

crrp 

Although the open systems interconnection 
(OSI) layered protocol reference model 
referred to above was conceived as applying 
to communication between computers using 
any ‘open’ communication network, many of 
its principles and techniques are applicable to 
the communication protocols between call- 
control processors at exchanges; that is, to 
CCITT No. 7 signalling. Within this context, 


the SCCP is considered to provide an OSI 
network layer service to its users. Because of 
this, the primitives between the SCCP and its 
users are referred to as network layer service 
primitives , and the name of each primitive is 
often preceded by ‘n-’, to indicate that it 
relates to network layer service; for example, 
‘N-CONNECT request ’. Similarly, the names of 
the primitives between the SCCP and the 
MTP are usually prefixed by ‘mtp-’; for 
example, ‘mtp-transfer indication ’. 

The application of the foregoing approach 
to the specification of the SCCP may be 
represented diagrammatically as shown in 
Figure 1. 

SCCP User Primitives 

Nine types of SCCP user primitive are speci¬ 
fied (excluding those for SCCP management). 
Their names and applicability to the four 
protocol classes are shown in Table 1, with 
details of the parameters included in each. A 
*?’ in the Table indicates that the use of the 
primitive in the manner implied is still under 
study in the CCITT. 


TABLE 1 

Summary of SCCP User Primitives and their Applicability to Protocol Classes 


Generic Name 

Specific Name 

Protocol Class 

Parameters 



0 

1 

2 

3 


N-UNITDATA 

Request 

* 

* 



CDA CGA SEQ RO UD 


Indication 

* 

* 



CDA CGA UD 

N-NOTICE 

Indication 

* 

* 

? 

? 

CDA CGA RR UD 

N-CONNECT 

Request 



* 

* 

CDA CGA RCS EDS 


Indication 



* 

* 

QOS UD Cl 


Response 



* 

* 

RA RCS EDS 


Confirmation 



* 

* 

QOS UD Cl 

N-DISCONNECT 

Request 



* 

* 

RA REA UD Cl 


Indication 



* 

* 

OR RA REA UD Cl 

N-DATA 

Request 



* 

* 

CR UD Cl 


Indication 



* 

* 


N-DATA ACKNOWLEDGE 

Request ? 




* 

Cl 


Indication 




* 


N-EXPEDITED DATA 

Request 




* 

UD Cl 


Indication 




* 


N-RESET 

Request 




* 

REA Cl 


Indication 




* 

OR REA Cl 


Response 




* 

Cl 


Confirmation 




* 


N-INFORM 

Request 



* 

* 

REA QOS Cl 


Indication 



* 

* 



Note : With the exception of n connect and n-disconnect, all of the primitives applicable to protocol classes 2 and 3 are also applicable to permanent 
signalling connections. 


CDA : called address 
CGA: calling address 

Cl: connection identification 
CR: confirmation request 
EDS : expedited data selection 
OR: originator 

QOS : quality of service parameter set 


RA : responding address 
RCS : receipt confirmation selection 
REA : reason 
RO: return option 
RR : reason for return 
SEQ : sequence control 
UD : user data 
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MTP Primitives 

Four generic primitives are specified for the 
interface between the SCCP and the MTP. 
They are listed in Table 2, with details of the 
parameters included in each. Further expla¬ 
nation may be found in a companion article 

[3]. 


TABLE 2 

Summary of SCCP-MTP Primitives 


Generic Name 

Specific Name 

Parameters 

MTP-TRANSFER 

Request 

Indication 

OPC DPC SLS 
SIO User Data 

MTP-PAUSE 

Indication 

Affected DPC 

MTP-RESUME 

Indication 

Affected DPC 

MTP-STATUS 

Indication 

Affected DPC 

Congestion 

(Level) 


SCCP MESSAGES AND PROCEDURES 
Summary of Types of SCCP Message 

Sixteen types of SCCP message are currently 
identified (excluding those for SCCP manage¬ 
ment), covering all of the four protocol classes. 
Their names, abbreviations and applicability 
to the protocol classes are shown in Table 3. 
Details of the parameters included in each 
message may be found in CCITT Recommen¬ 
dation Q.713, Tables 3-18. The functions of 
messages and the relationships between the 
messages and associated primitives are 
described below. 

Messages and Procedures for Connec¬ 
tionless Protocol Classes (0 and 1) 

Unitdata (UDT) 

This message is the means of conveying data 
in the connectionless mode. It is generated 
by the SCCP (at the end originating the 
data) on reception of an n-unitdata request 
primitive from the SCCP user. On reception 
of a unitdata message, the SCCP at the desti¬ 
nation node passes an n-unitdata indication 
primitive to the relevant user. A return option 
is provided to facilitate the return of a message 
which cannot be delivered. 

Unitdata Service (UDTS) 

This message is the means by which the SCCP 
at an intermediate or destination node indi¬ 
cates to the SCCP which has originated a 
unitdata message, that it is unable to deliver 
the unitdata message. It contains an indi¬ 
cation of the reason for non-delivery, and 
the contents of the undelivered message. On 
receiving this message, the SCCP passes an 
N-NOTICE indication primitive to the user that 
originated the n-unitdata request primitive. 


Messages and Procedures for Connec¬ 
tion-Oriented Protocol Classes (2 and 3) 
(Temporary Signalling Connections) 

Connection Request (CR) 

This message is sent by the SCCP on reception 
of an N-CONNECT request primitive from one 
of its users, to set up a signalling connection 
to a remote SCCP user. The destination 
SCCP, on reception of the connection request 
message, passes an n-connect indication 
primitive to the required SCCP user. Any 
intermediate SCCPs receiving this message 
pass it to the next appropriate SCCP to estab¬ 
lish the connection. 

Connection Confirm (CC) 

On reception of an n-connect indication 
primitive, an SCCP user normally responds 
by passing an n-connect response primitive to 
its SCCP. The SCCP then sends a connection 
confirm message back to the SCCP that orig¬ 
inated the message. That SCCP, on reception 
of the connection confirm message, passes an 
n-connect confirmation primitive to the user 


TABLE 3 

Summary of Message Types and their Applicability to 
Protocol Classes 


Name 

Abbreviation 

Protocol Class 

0 

1 

2 

3 

Unitdata 

UDT 

* 

* 



Unitdata service 

UDTS 

* 

* 



Connection request 

CR 



* 

* 

Connection confirm 

CC 



* 

* 

Connection refused 

CREF 



* 

* 

Released 

RLSD 



* 

* 

Release complete 

RLC 



* 

* 

Data form 1 

DTI 



* 


Data form 2 

DT2 




* 

Data acknowledgement 

AK 




* 

Expedited data 

ED 




* 

Expedited data ack. 

EA 




* 

Reset request 

RSR 




* 

Reset confirm 

RSC 




* 

Protocol data unit error 

ERR 



* 

* 

Inactivity test 

IT 



* 

* 


Note : With the exception of connection request, connection confirm , connection refused , released and 
release complete , all of the messages applicable to protocol classes 2 and 3 are also applicable to 
permanent signalling connections. 
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that originated the N-CONNECT request primi¬ 
tive. Any intermediate SCCPs receiving this 
message send it to the next SCCP in the 
connection. 

Connection Refused (CREF) 

This message is the means by which an SCCP 
that has received a connection request 
message indicates to the SCCP that originated 
the message that it is unable to establish the 
connection. Its generation may be initiated by 
an intermediate SCCP or by the destination 
SCCP, owing to, for example, lack of 
resources. Its generation may also be initiated 
by the destination user, if the user so wishes, 
by passing to its local SCCP an n-disconnect 
request primitive instead of an N-CONNECT 
response primitive. 

When the SCCP that originated a connec¬ 
tion request message receives a corresponding 
connection refused message, it passes a N- 
disconnect indication primitive to the appro¬ 
priate originating local user. 

Released (RLSD) and Release Complete 
(RLC) 

When an SCCP user at either end of a signal¬ 
ling connection wishes to release the connec¬ 
tion, it passes to its local SCCP an n-discon- 
nect request primitive. The local SCCP 
initiates release of the connection by sending 
a released message to the next SCCP in the 
connection. On reception of a released 
message, any intermediate SCCP sends a fur¬ 
ther released message to the next SCCP, and 
returns a release complete message to the 
SCCP from which it received the released 
message. This process is repeated at all inter¬ 
mediate SCCPs until the SCCP at the remote 
end of the connection receives a released 
message. The remote SCCP, also, sends a 
release complete message back, but in 
addition passes an n-disconnect indication 
primitive to the appropriate local user. 

Data Form 1 (DTI) and Data Form 2 (DT2) 

These are the basic data messages by which 
an SCCP transfers user data to another SCCP 
using a signalling connection. Which type 
is applicable depends on the protocol class 
selected. An SCCP user wishing to send data 
over an established connection passes an N- 
data request primitive (which contains, as a 
parameter, the data to be transferred) to its 
local SCCP, which assembles the data in the 
appropriate data message. On reception of 
the data message, the receiving SCCP passes 
an n-data indication primitive (containing the 
transferred data) to the appropriate user. 

Data Acknowledgement (AK) 

Data acknowledgement messages are orig¬ 
inated by an SCCP that is receiving data 
messages, as a means of acknowledging recep¬ 
tion of those data messages and for regulating 


their flow. The acknowledgement of data 
messages takes place independently on all of 
the connection sections comprising the signal¬ 
ling connection. An option is provided 
whereby the SCCP user can receive acknowl¬ 
edgement by means of an n-data acknowl¬ 
edge indication primitive. Whether this 
option is exercised by means of the confir¬ 
mation request parameter in the n-data 
request primitive, or by means of a separate 
N-data ACKNOWLEDGE request primitive is cur¬ 
rently under study by the CCITT. 

Expedited Data (ED) and Expedited Data 
Acknowledgement (EA) 

The expedited data transfer facility may be 
used on an established signalling connection 
to send urgent messages so that they are 
not subject to the flow-control mechanisms 
applicable to data messages. The maximum 
permitted length of the user data field in an 
expedited data message is 32 octets, and no 
segmentation/reassembly is possible. 

An SCCP user wishing to use the facility 
passes an n-expedited data request primitive 
(containing as a parameter the data to be 
sent) to its local SCCP. The local SCCP then 
assembles an expedited data message and 
sends it to the destination SCCP. An inter¬ 
mediate or destination SCCP, on receiving the 
expedited data message, sends an expedited 
data acknowledgement message back to the 
preceding SCCP. The destination SCCP also 
passes an n-expedited data indication primi¬ 
tive (containing the data as a parameter) to 
the appropriate local user. 

The SCCP that sent the first expedited 
data message is not allowed to send a further 
expedited data message until it has received 
an expedited data acknowledgement message 
relating to the first message. 

Reset Request (RSR) and Reset Confirm 
(RSC) 

The purpose of the reset procedure is to reinit¬ 
ialise the message sequence numbers on an 
established signalling connection. It may be 
initiated by the SCCP user or by the SCCP 
itself at either end of the connection, or by an 
intermediate SCCP. 

An SCCP user wishing to initiate a reset 
passes an N-RESET request primitive to its local 
SCCP. The local SCCP sends a reset request 
message to the SCCP at the remote end of 
the connection section. If the SCCP initiates 
a reset, it passes an n-reset indication primi¬ 
tive to the local user. The local user should 
then pass an n-reset response primitive to the 
SCCP. 

An intermediate SCCP, on reception of the 
reset request message, sends a reset confirm 
message back to the SCCP which sent the 
reset request message, and sends a reset 
request message on the associated connection 
section. 
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The destination SCCP, on reception of the 
reset request message, passes an n-reset indi¬ 
cation primitive to the appropriate local user. 
When the destination SCCP receives an N- 
reset response primitive from the local user, 
it sends a reset confirm message to the SCCP 
from which it received the reset request 
message 

On reception of the reset confirm message, 
the originating SCCP passes an n-reset con¬ 
firmation primitive to the local user. 

Protocol Data Unit Error (ERR) 

This message is sent on detection of protocol 
errors, of which three types are currently 
identified: 

(a) syntax errors in which the format of 
a received message does not conform to the 
rules; 

( b ) logical errors in which a received 
message is inappropriate to the state of the 
connection; and 

(c) transmission errors for example, 
message loss or excessive delay. 

Various actions may be taken on reception 
of a protocol data unit error message, 
depending on the nature of the error. 

Inactivity Test (IT) 

The inactivity test message may be sent 
periodically by the SCCP at either end of an 
established signalling connection to verify that 
the connection is still active. The procedure is 
desirable to allow recovery from the loss of 
a connection confirm message, or from the 
unsignalled termination of a signalling con¬ 
nection, or from a discrepancy between the 
connection data held at the two ends of the 
connection. 

The procedure operates by setting time¬ 
outs at each end of each connection section. 
Whenever a message is sent, the send timer 
is reset, and whenever a message is received, 
the receive timer is reset. If the send time-out 
expires, an inactivity test message is sent, and 
if the receive time-out expires, the connection 
is released. 

Messages and Procedures for Perma¬ 
nent Signalling Connections 

With the exception of the procedures associ¬ 
ated with the connection request , connection 
confirm , connection refused , released , and 
release complete message, all of the pro¬ 
cedures applicable to protocol classes 2 and 3 
are also applicable to permanent signalling 
connections. However, if, during the inactivity 
test procedure, the receive time-out expires, 
the connection is not released but manage¬ 
ment is informed. 

Structure of SCCP Messages 

The SCCP formats messages to be fitted into 
the standard SIF of the MTP, which in future 


will allow for up to 272 octets. Each message 
consists of the following parts: 

• a service information octet (SIO) as speci¬ 
fied for the MTP; 

$ a standard routing label as specified for 
the MTP; 

$ a message type octet to indicate the type 
of SCCP message; 

• a mandatory fixed (length) part; 

• a mandatory variable (length) part; and 

• an optional part (if required). 

Mandatory Fixed Part 

For a given message type, certain parameters 
must be included and are of fixed length, and 
these are contained in the mandatory fixed 
part of the SCCP message. Not only the 
length, but also the position of these par¬ 
ameters is specified by the message type octet. 

Mandatory Variable Part 

For a given message type, certain parameters 
must be included, but are of a length which 
cannot be anticipated by the SCCP. These 
are contained in the mandatory variable part 
of the SCCP message. Because of the unpre¬ 
dictable length, the position of the start of 
each parameter is indicated by a pointer 
(PNTR) octet. The name of each parameter, 
and the order of the pointers are implicit in the 
message type. The names of the parameters in 
this part of the message are therefore not 
included. 

If the message type indicates that the 
message may contain also an optional part, 
the mandatory variable part will include a 
pointer to indicate the start of the optional 
part. If, in a particular instance, the option 
for inclusion is not exercised, the coding of 
the pointer is all zeros. 

Optional Part 

The option for inclusion or otherwise of these 
parameters is exercised by the user of the 
SCCP. 

Within the optional part of the message, 
whose start is indicated by a pointer as 
described above, each optional parameter is 
identified by a discrete ‘name’ which is coded 
as a single octet. Its length is indicated by a 
further length indicator (L.IND) octet. The 
order is determined by the rule ‘name, length, 
value’. In other words, each optional par¬ 
ameter immediately follows its own name and 
length octets. No pointers are used within the 
optional part of the message. 

A further octet (all zeros) is added at the 
end of the last optional parameter to indicate 
the end of the set of optional parameters. 

SCCP Message Fields 

Seventeen parameter fields are specified for 
possible inclusion in SCCP messages. Their 
inclusion or otherwise in any particular 
message depends on the message type and on 
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TABLE 4 

Summary of Parameter Fields included in SCCP Messages 



Messages 

Parameter 

U 

U 

C 

C 

c 

R 

R 

D 

D 

A 

E 

E 

R 

R 

E 

I 

Fields 

D 

D 

R 

c 

R 

L 

L 

T 

T 

K 

D 

A 

S 

S 

R 

T 


T 

T 



E 

S 

c 

1 

2 




R 

c 

R 




S 



F 

D 











Message type 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

Dest. loc.ref. 




M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

Source loc.ref. 



M 

M 


M 

M 






M 

M 


M 

Called address 

M 

M 

M 

O 

O 












Calling address 

M 

M 

O 














Protocol class 

M 


M 

M 












M 

Segment. & 








M 









Reass. 

















Rec.seq. number 










M 







Seq. & segment 









M 







M 

Credit 



0 

0 






M 






M 

Release cause 






M 











Diagnost 


M 




0 







O 


0 


Reset cause 













M 




Error cause 















M 


User data 

M 

M 

0 

O 

O 

O 


M 

M 


M 






Refusal cause 





M 












End of opt.pars 



o 

o 

O 

o 







O 


O 



the options exercised by the SCCP user. A 
summary of the mandatory (M) and optional 
(O) fields for inclusion in the SCCP messages 
is given in Table 4, followed by an explanation 
of their contents. 

• Message type The message type code 
field is present in all SCCP messages. It uni¬ 
quely identifies the type of message (for 
example, UDT, UDTS, or CR, etc.) as 
described above. 

• Destination local reference number 
(Dest.Loc.Ref.) This field uniquely ident¬ 
ifies a signalling connection at its destination. 
It is an internal working number chosen by the 
destination of the connection independently of 
the origin of the connection. 

• Source local reference number (Source 
Loc.Ref.) This field uniquely identifies a sig¬ 
nalling connection at its origin. It is an internal 
working number chosen by the origin of the 
connection independently of the destination 
of the connection. 

• Called address The called (party) 
address contains sufficient information to 
identify uniquely the destination signalling 
point of the SCCP message, and a particular 
subsystem at that signalling point. 

In connectionless messages, the called 
address identifies the destination of the 


message. In connection-oriented messages the 
called address identifies the terminating end 
of the signalling connection. 

It may consist of any combination of global 
title (for example, dialled digits), signalling 
point code and/or subsystem number. For 
ease of interpretation, it contains additional 
information to indicate which type of 
addressing elements are present. Figure 2 
shows an example of the format where a 
global title is present, with an indication of the 
number of bits allocated to each parameter. 

The translation type octet is used by a 


ADDRESS 

ADDRESS 

INDICATOR 

NUMBERING 

PLAN 

ENCODING 

SCHEME 

TRANSLATION 

TYPE 

8 MINIMUM 

_ t 

8 

4 4 8 

\_ 


RESERVED FOR 

ROUTING 

GLOBAL TITLE FORMAT 

SUBSYSTEM 

POINT CODE 

NATIONAL USE 

INDICATOR 

INDICATOR 

INDICATOR 

INDICATOR 


11 4 11 


Figure 2—Format of called address field 
in SCCP message 
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receiving SCCP to select the translation table 
appropriate to the address information. It may 
relate to a particular service; for example, 
Freephone. 

The encoding scheme field indicates 
whether the address information consists of 
binary-coded decimal (BCD) or International 
Alphabet No. 5 (IA5) characters. 

The numbering plan field is used to indicate 
whether the global title uses the telephone/ 
ISDN, Telex, data network, mobile network 
or other numbering plan. 

The composition of the address indicator 
octet is also shown in Figure 2. The first two 
bits are used to indicate the presence or other¬ 
wise of a signalling point code and of a subsy¬ 
stem (SCCP user) number. The four bits of 
the global title format indicator indicate the 
presence or otherwise of a global title, and 
identify any one of up to 15 different types of 
global title. The routing indicator is used 
by a receiving SCCP to determine whether 
onward routing should be based on signalling 
point code plus subsystem number, or on 
global title (in which case local translation 
would be required). The last bit may be used 
to indicate whether the address is an inter¬ 
national number/point code or a national 
number/point code. 

The address field contains the digits of the 
address. 

@ Calling address The calling (party) 
address contains sufficient information to 
identify uniquely the originating signalling 
point of the SCCP message. 

In connectionless messages the calling 
address identifies the origin of the SCCP 
message. In connection-oriented messages the 
calling address identifies the origin of the 
signalling connection. 

Its composition is similar to that of the 
called address. 

• Protocol class For connectionless service, 
this is used to indicate whether a message 
should be returned in the event of the detection 
of an error by the receiving SCCP. 

For connection-oriented service, it is the 
means by which the protocol class is nego¬ 
tiated between the two ends of a signalling 
connection. 

• Segmenting/reassembling (Segment. & 
Reass.) This field is set by the SCCP sending 
data to indicate to the destination SCCP 
whether more data will follow in a subsequent 
message, and consequently whether reas¬ 
sembly of the data will be required at the 
receiving end. The first bit is used as a ‘more 
data’ indicator. 

• Receive sequence number (Rec.Seq. 
Number) This is used in the data acknowl¬ 
edgement message as a means of flow control. 

• Sequencing!segmenting (Seq.& Segment.) 

This field contains information required for: 

sequence numbering, flow control, segmen¬ 


tation and reassembly. It consists of the 
sequence number of the message sent, the 
receive sequence number and the ‘more data’ 
indicator. 

® Credit This is used in a data acknowl¬ 
edgement message to indicate to the sending 
SCCP how many messages it may send on 
that signalling connection without awaiting 
acknowledgement. It is also used in a connec¬ 
tion request message to propose a credit value, 
and in the connection confirm message to 
select a credit value. 

• Release cause This is used in the released 
message to indicate the reason for the release. 

# Diagnostic (Diagnost) For connection¬ 
less protocol classes, this is used in the unit- 
data service message to indicate the reason 
for the return of a unitdata message. 

The use of this field in connection-oriented 
protocol classes is still under study in the 
CCITT. 

G Reset cause This field is used in a reset 
request message to indicate the reason for 
invoking the reset procedure. 

• Error cause This field is used in the pro¬ 
tocol data unit error message to indicate the 
nature of the protocol error. 

Q User data This field contains any infor¬ 
mation that is to be transferred transparently 
from the originating SCCP user to the desti¬ 
nation SCCP user. 

O Refusal cause This field is used in a con¬ 
nection refused message to indicate the reason 
why the connection cannot be established. 

# End of optional parameters (End of 
Opt.Pars.) This field is present in all mess¬ 
ages which contain optional parameters, to 
indicate the position of the end of the set of 
optional parameters in the message. 

Example of an SCCP Message 

Figure 3 shows how the SCCP constructs a 
unitdata message from the parameters sup¬ 
plied by the user in the N-UNITDATA request 
primitive. The resultant message is then 
assembled into a mtp-transfer request primi¬ 
tive and passed to the MTP for transmission. 
A companion article describes the compo¬ 
sition of MTP messages in more detail [3]. 

SCCP MANAGEMENT PROCEDURES 
General 

SCCP management (SCMG) provides pro¬ 
cedures to maintain network performance by 
re-routing or throttling signalling traffic in the 
event of failure or congestion of signalling 
points, or of subsystems within the signalling 
points. These SCMG procedures apply to both 
connection-oriented and connectionless ser¬ 
vices of the SCCP, and rely on nodal failure, 
recovery, and congestion information pro¬ 
vided by MTP primitives, and on subsystem 
failure and recovery information received in 
SCMG messages. 

Current SCMG procedures are designed to 
manage solitary nodes/subsystems and repli- 
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Figure 3 

Total composition of 
an SCCP unitdata 
message 


cated nodes/subsystems which operate in a 
dominant mode and for which any given pri¬ 
mary node/subsystem has only one back-up 
(that is, duplicated nodes/subsystems). Man¬ 
agement procedures for operating in a mode 
other than the dominant mode, or for nodes/ 
subsystems which have more than one backup, 
are for further study. (Dominant mode means 
that when a failed primary node/subsystem 
recovers, signalling traffic which has been 
diverted to its duplicate is returned to the 
primary.) 

Messages which have the called party 
address specified in the form of a global title, 
can be routed to different signalling points 
and/or subsystems, depending on network or 
subsystem status. 

In order to limit the number of management 
messages propagated by these procedures, 
SCMG utilises the concept of a ‘concerned’ 
subsystem or signalling point. Management 
messages are broadcast from a node only 
to a ‘concerned’ entity. A ‘concerned’ entity 
means an entity with an immediate need to 
be informed of a particular signalling point/ 
subsystem status change, independently of 
whether SCCP communication is in progress 
between the ‘concerned’ entity and the 
affected entity whose status has changed. 

SCMG is organised into two subfunctions: 
signalling point status management and sub¬ 
system status management. 


Signalling Point Status Management 

Signalling point status management facili¬ 
tates the alternative routing of signalling 
traffic to backup signalling points and/or 
backup subsystems if applicable. The SCCP 
translation function and status marks are 
updated, based on the information of network 
failure, recovery or congestion provided by 
the MTP-PAUSE, MTP-RESUME, Or MTP-STATUS 
indication primitives, and messages received 
are subsequently re-routed if appropriate. 

Based on the information received, local 
subsystems are informed of every change of 
signalling point status, so that the relevant 
action can be taken by the SCCP users. 

Subsystem Status Management 

Subsystem status management allows alterna¬ 
tive routing to backup subsystems should a 
primary subsystem fail. The SCCP translation 
function and status marks are updated based 
on received information relating to failure, 
withdrawal, and recovery of subsystems. 
Enhancements to take account also of subsy¬ 
stem congestion are presently under study. 
Local users are informed of the status of 
their backup subsystems, since they have the 
responsibility for reducing or inhibiting sig¬ 
nalling traffic for the affected subsystem. 

Primitives 

The SCMG primitives used between the 
SCCP and its users are: 

N-COORD 

The n-coord primitive is used by replicated 
subsystems to co-ordinate the withdrawal 
from service of one of the subsystems. 

N-STATE 

The N-STATE request primitive is used to 
inform SCMG about the status of the orig¬ 
inating SCCP user. The n-state indication 
primitive is used to inform an SCCP user 
accordingly. 

N-PCSTATE 

The N-PCSTATE indication primitive is used to 
inform an SCCP user about the status of a 
signalling point. 

Table 5 gives an overview of the primitives 
to the SCCP user and the corresponding par¬ 
ameters for SCMG. 

® Affected subsystem This parameter 
identifies an SCCP user which is failed, with¬ 
drawn, congested, or allowed. The affected 
subsystem parameter contains the same type 
of information as the called address and 
calling address. 

• Subsystem multiplicity indicator The 
parameter subsystem multiplicity indicator 
identifies the number of replications of a sub¬ 
system. 
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TABLE 5 

SCCP Management Primitives and 
Parameters 


Primitives 

Parameters 

Generic 

Name 

Specific Name 

N-COORD 

Request 

Indication 

Response 

Confirmation 

Affected subsystem 
Subsystem multi¬ 
plicity indicator 

N-STATE 

Request 

Indication 

User status 

Affected subsystem 
Subsystem multi¬ 
plicity indicator 

n-pcstate 

Indication 

Affected point code 
Signalling point 
status 


© User status The parameter user status is 
used to inform an SCCP user of the status 
of the affected subsystem. User status may 
assume the values: user-in-service and user- 

OUT-OF-SERVICE. 

# Affected point code This parameter 
identifies a signalling point which is failed, 
congested, or allowed. The affected point code 
parameter contains unique identification of a 
signalling point. 

# Signalling point status The parameter 
signalling point status is used to inform a user 
of the status of an affected signalling point. 
Signalling point status may assume the fol¬ 
lowing values: signalling point inaccessible, 

SIGNALLING POINT CONGESTED, and SIGNALLING 
POINT ACCESSIBLE. 


SCMG Messages 

SCMG messages are transferred by means 
of the connectionless service of the SCCP. 
Unitdata (UDT) messages are employed using 
protocol class 0 with the ‘discard message on 
error’ option selected. The SCMG message 
information is contained in the data par¬ 
ameter of the unitdata message, as shown in 
Table 6. 

The parameter ‘SCMG format identifier’ 
uniquely defines the function and format of 
each SCMG message. These messages are: 

Subsystem allowed (SSA), 

Subsystem prohibited (SSP), 

Subsystem status test (SST), 

Subsystem out-of-service request (SOR), 
and 

Subsystem out-of-service grant (SOG). 

With the exception of user (subsystem) 
status information, the data parameters in 
each SCMG message are used to convey the 
information contained in the corresponding 
parameters of the appropriate primitive. User 


TABLE 6 

SCCP Management Message Format 


Parameter 

Message type ( = unitdata) 

Protocol class and options 


( = Class 0, no message return) 


Called party address 


(SSN = SCCP management) 


Calling party address 


(SSN = SCCP management) 


SCMG format identifier 

Note I 

Affected subsystem number 

Note 1 

Affected point code 

Note l 

Subsystem multiplicity indicator 

Note 1 


Note 1: These parameters are conveyed in the data field of the unitdata 
message. 


status information is conveyed by means of 
the SCMG format identifier. 

Subsystem Status Test Procedure 

The subsystem status test procedure provides 
a means of checking the status of a subsystem 
marked prohibited. 

Periodically, a subsystem status test (SST) 
message is sent to SCMG at the node which 
has previously indicated the failure of a local 
subsystem. If that subsystem is now allowed, 
a subsystem allowed (SSA) message is 
returned; if that subsystem is still prohibited, 
no indication is returned. 

Co-ordinated State Change Procedure 

This procedure allows one member of a group 
of duplicated subsystems to go out of service 
for software updates or modifications, without 
interfering with normal network operation. In 
essence, it requires that a subsystem that has 
to be taken out of service first verifies that its 
duplicate can take over the load. Only on 
reception of a positive indication that it is able 
to do so will the first subsystem go out of 
service voluntarily. 

A subsystem wishing to go out of service 
passes an N-COORD request primitive to its local 
SCMG. SCMG then sends a SOR message to 
SCMG at the node of the backup subsystem, 
which then passes an n-coord indication 
primitive to the backup subsystem. If the 
backup subsystem is able to take over, it passes 
an n-coord response primitive to its local 
SCMG, which then sends a SOG message to 
the requesting node. On reception of the SOG 
message, the requesting SCMG passes an N- 
coord confirmation primitive to the 
requesting subsystem, and initiates a broad¬ 
cast of SSP messages to concerned signalling 
points. If the backup subsystem is unable to 
take over, the requested node does not reply 
to the SOR message. 
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Local Broadcast Procedure 

The local broadcast procedure is used to 
inform local subsystems, of any related subsy¬ 
stem status information received at, or 
observed by, the node. The information which 
can be locally broadcast is: user-out-of-ser¬ 
vice, user-in-service, signalling point inaccess¬ 
ible, signalling point accessible, and signalling 
point congested. This information is contained 
in the n-state indication primitive. 

Broadcast Procedure 

The broadcast procedure provides a mech¬ 
anism that may be used to inform concerned 
signalling points of any related subsystem 
status change at local or adjacent signalling 
points. The messages that may be broadcast 
are subsystem prohibited and subsystem 
allowed. In some network situations, the 
number of concerned signalling points will be 
zero, and no broadcast of SCMG messages 
will occur. In these cases, SCMG messages 


will be transferred to signalling points, when 
they originate messages, by means of a 
response mechanism only. 

ADDRESSING AND ROUTING OF SCCP 
MESSAGES 

Figure 4 shows a possible application of one 
of the connectionless protocol classes of SCCP 
service for routing messages. The example 
chosen is a limiting case of an exchange 
applying to a remote database for infor¬ 
mation. Exchange (A), which initiates the 
request to the database, is referred to as the 
database access node (DAN). The inter¬ 
mediate exchange (B), which is the one kept 
up-to-date on the availability status of the two 
databases (C and D), is referred to as the 
translator. (The DAN and translator func¬ 
tions are shown implemented at different 
nodes to indicate clearly how these functions 
interact. These functions could be performed 
by the same node). 


Figure 4 

Typical addressing and 
routing of SCCP 
messages 



(a) Initial forward message 



(b) Backward message 



(c) Subsequent forward message 
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The sequence of events is described in the 
following paragraphs. 

Although it is not shown in the figure, it is 
necessary to assume that a circuit-switched 
path has been set up in the usual way from 
the originating customer to the DAN (exch¬ 
ange A), which may be a local exchange or a 
DMSU. The DAN recognises, typically, from 
the dialled digits that information is required 
from a database before establishment of the 
call can proceed. 

Call processing at the DAN passes an N- 
unitdata request primitive to the SCCP, 
using the dialled digits as a global title (GT) 
for the called address (CDA) parameter. The 
calling address (CGA) consists simply of the 
signalling point code of the DAN together 
with subsystem number (SSN) X to identify 
the relevant call processing entity at the DAN 
that originated the message. 

The SCCP at the DAN assembles a unit- 
data message. Using the global title supplied 
in the n-unitdata request primitive, it refers 
to its translation table, which in this case 
indicates that the message should be sent to 
exchange B. It therefore assigns DPC ‘B’ to 
the mtp-transfer request primitive, together 
with OPC ‘A’. The translation function at the 
DAN also sets the routing indicator (RI) to 
‘global title routing’ (GTR). This is used by 
the receiving SCCP (in this case the trans¬ 
lator) as an indication that it should perform 
a translation on the global title to determine 
the onward routing of the message. 

The SCCP at the translator, examines the 
routing indicator and applies to its translation 
function with the global title as called address. 
The translation function refers to its table 
showing the availability status of the data¬ 
bases and their subsystems which could deal 
with the request. It selects the active subsy¬ 
stem which is to deal with this particular 
request, adds its subsystem number (SSN) to 
the called address, passes the DPC to the 
MTP, and sets the routing indicator to ‘point 
code routing’ (PCR). 

The SCCP at the database (C), noting that 
the message is point code routed, by-passes 
its translation function and passes the message 
directly to subsystem ‘Y’. Subsystem ‘Y’ then 
operates on the user data within the message 
to derive the information required by call 
processing at the DAN. It then assembles 
a unitdata message containing the required 
information as user data. The routing indi¬ 
cator is set to PCR and the message is point 
code routed to the DAN, by-passing the SCCP 
at the translator node, and using as DPC in 
the called address, the OPC of the received 
message. 

Any subsequent messages in the forward 
direction relating to the same transaction are 
also point code routed directly to database 
‘C’, since the DAN now knows the identity of 
the database and of its subsystem which is 
dealing with the request. 


CONCLUSIONS 

This article describes the operation of the 
signalling connection control part of CCITT 
Signalling System No. 7, based on the latest 
documentation available from the CCITT. 
Despite the effort devoted to the CCITT 
activities on the SCCP in the 1985-1988 
Study Period, there are several aspects of the 
SCCP which are not yet fully specified. Some 
additional work will therefore be required 
before the CCITT Recommendations can be 
implemented. Also, the Recommendations 
that will appear in the CCITT Blue Book in 
1988/9 contain some options which have been 
omitted from this article for clarity. It should 
not be assumed that the options which are 
included in this article are necessarily those 
which BT would wish to implement. It is 
possible that the initial implementation of the 
SCCP by BT will support only protocol classes 
0 and 1, and will also provide some additional 
SCCP management procedures to ensure sat¬ 
isfactory operation under subsystem conges¬ 
tion conditions. 

GLOSSARY 

Connection-Oriented Data Transfer 

This is data transfer in which an association 
is established between sender and receiver 
before any attempt is made to transfer the 
data. It avoids the risk of flooding the network 
with undeliverable messages if the intended 
recipient is unable to receive them at that 
time. The association could take the form of 
a physical connection, but this is not essential. 
The most usual form of association is that of 
a logical (or virtual) connection. In this, the 
originator sends a request to the intended 
recipient of the data to ask whether the data 
can be accepted. If the intended recipient 
responds with confirmation that it is able to 
receive the data, the logical connection is 
considered to be established, and data transfer 
may start. A complementary procedure is used 
to release the logical connection. 

The packet-switched service uses this mode 
of operation. 

Connection-oriented procedures are useful 
when a large amount of data needs to be 
transferred. 

Connectionless Data Transfer 

This is data transfer which takes place without 
confirmation that the intended recipient is 
able to receive it at that time. Where small 
amounts of data are to be transferred, this 
method can be efficient, because it avoids the 
overhead of the additional messages which 
would be required to establish and release a 
logical or physical connection. 

(Communication) Protocol 

This embraces all that is necessary to facilitate 
communication between two nodes in a net- 
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work. Its specification consists of the definition 
of messages, primitives and procedures. 

Protocol Specification 

A feature of the layered approach to protocol 
specification is that each layer is considered 
to provide services to the layer above, which 
is referred to as a user of those services. An 
aspect of particular importance is the method 
of distinguishing inter-node messages (which 
have to be specified in the finest detail), from 
signals between protocol layers within each 
communicating node (which need to be speci¬ 
fied only in sufficient detail to define their 
essential information content). For the pur¬ 
pose of writing the specification, each of these 
signals is referred to as a primitive , and each 
piece of essential information conveyed by it 
is referred to as a parameter. 

Messages 

Messages are the quintessence of modern sig¬ 
nalling systems, being the sole means by which 
information is transferred from one node to 
another. Because each node in a network or 
between networks may have been obtained 
from different suppliers, it is necessary to 
specify messages precisely. Consequently, 
protocol specifications include detailed 
message formats, and coding of the individual 
bits representing the values of all parameters 
included in each message. 

Primitives 

The nature of primitives is entirely the con¬ 
cern of the designer of the node, and should 
consequently not be constrained by the pro¬ 
tocol specification. A primitive comprises 
information or instructions passed between 
protocol layers within a node. On the assump¬ 
tion that the entire node is designed and built 
by the same supplier, there is no need for the 
purchaser of the system to specify, or be aware 
of, the electrical nature of the primitives. Only 
the meaning of the primitives needs to be 
specified, including the parameters which are 
essential for conveying that meaning. 

Primitives are often described by the name 
of the layer of the underlying functional block 
which supports them. 

Each generic primitive associated with a 
particular function may exist in up to four 
basic forms, depending on the nature of the 
function. These are: request , indication , 


response and confirmation. They are used in 
the following way: 

Request This type of primitive is gener¬ 
ated by a user to request that a specified 
function be performed. 

Indication This is passed to the user to 
inform that user that a specified function is 
being performed. The same primitive is used 
whether execution of the function was 
initiated by the network or by another user 
invoking the corresponding request primitive. 

Response This is passed from the user to 
the network to indicate that the user acknowl¬ 
edges reception of the corresponding Indi¬ 
cation primitive. 

Confirmation This is passed from the net¬ 
work to the user to indicate to the user that 
the action required as a result of passing an 
earlier request primitive has been carried out. 
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CC1TT Signalling System Wo. 7 : Integrated Services 
Digital Network User Part 

C. G. DAVIES, M.B.i.M.t 

UDC 621.395.34 

The specification of the CCITT Signalling System No. 7 integrated services digital network user 
part (ISUP) is about to be defined by the CCITT in the 1988 Blue Book Recommendations (Q.761-764 
and Q.730). This article gives an overview of the ISUP and describes the basic call-control and 
signalling procedures necessary for the establishment, supervision and the clearing of a connection 
in an ISDN environment. In addition, the services expected to be specified in the 1988 CCITT 
Recommendations are listed. 


OVERVIEW OF THE ISDN USER PART 

The integrated services digital network user 
part (ISUP) is the protocol which provides 
the signalling functions required by CCITT 
No. 7 signalling to support basic bearer ser¬ 
vices and supplementary services for voice 
and non-voice applications in an integrated 
services digital network (ISDN). 

The ISUP is suited for application in dedi¬ 
cated telephone and circuit-switched data net¬ 
works and in analogue and mixed analogue/ 
digital networks. In particular, the ISUP 
meets the requirements defined by the CCITT 
for world-wide international semi-automatic 
and automatic telephone and circuit-switched 
data traffic. 

The ISUP can be used for national and 
international applications. The signalling pro¬ 
cedures, information elements and message 
types specified are for both applications. 
Coding space has been reserved to allow 
national administrations and recognised pri¬ 
vate operating agencies to introduce network- 
specific signalling messages and elements of 
information within the protocol structure. 

The ISUP makes use of the services pro¬ 
vided by the message transfer part (MTP)[1] 
and, in some cases, by the signalling connec¬ 
tion control part (SCCP)[2] of CCITT No. 7 
signalling for the transfer of information 
between ISDN user parts. 


SERVICES SUPPORTED BY THE ISDN 
USER PART 

The ISUP protocol supports the basic bearer 
service; that is, the establishment, supervision 
and release of 64 kbit/s circuit-switched net¬ 
work connections between customer line exch¬ 
ange terminations. 

In addition to the basic bearer service, the 
ISUP is expected to support (in the 1988 


t Network Planning and Works Department, Bri¬ 
tish Telecom UK Communications 


Recommendations) the following supplemen¬ 
tary services: 

• calling line identification (presentation and 
restriction), 

• call forwarding, 

• closed user group, 

• direct dialling-in, and 

• user-to-user signalling. 

GENERAL PROCEDURES 

In general, the call set-up procedures for both 
voice and non-voice calls are similar and may 
use both en bloc and overlap (digit-by-digit) 
signalling. 

The basic call-control procedures are div¬ 
ided into three phases: call set-up, data/ 
conversation, and call clear down. Messages 
on the signalling link are used to establish and 
terminate the different phases of the call. Five 
basic connection types may be established: 

(a) speech, 

( b) 3*1 kHz audio, 

(c) 64 kbit/s unrestricted, 

( d) alternate speech/64 kbit/s unre¬ 
stricted, or 

( e ) alternate 64 kbit/s unrestricted/speech 

Inband tones and/or recorded announce¬ 
ments are returned to the caller on speech and 
3 • 1 kHz connections to provide information 
on call progress. Calls originating from ISDN 
terminals may be supplied with more detailed 
call-progress information by means of 
additional messages in the access protocol (D- 
channel). 

SIGNALLING PROCEDURES FOR CALL 
ESTABLISHMENT AND CLEARING 

The procedure used to establish a voice or 
non-voice call is similar to that described in a 
companion article on BT’s national user part 
(NUP)[3]; however, a number of differences 
do exist. A brief description of the call-estab¬ 
lishment and clearing procedures is given 
below. 
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Figure 1 

Call establishment 
example 


Figure 2 

Normal call release 


Figures 1 and 2 show the basic call-estab¬ 
lishment and release procedures for a suc¬ 
cessful call together with the ISUP messages 
used. 

Appendix 1 details the structure of an 
ISDN message and lists the messages and 
parameters names. Appendix 2 details the 
general functions of the ISUP messages. 
Appendix 3 details the signalling information 
parameters and functions. 

Successful Call Set-up Procedures at the 
Originating Exchange 

When the originating exchange has received 
sufficient selection information (for example, 
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(a) Calling user clears 


digits from the calling user to route the call) 
selection of a free inter-exchange circuit takes 
place and an initial address message (IAM) 
is sent to the succeeding exchange (see 
Appendix 1 for formats and codes). The selec¬ 
tion of the route depends on the called-user 
number, the type of connection required and 
the network signalling capability required. 

The IAM may contain all or part of the 
information necessary to determine the 
routing of the call; for example, digits, trans¬ 
mission medium requirement and forward call 
indicators etc. If the IAM contains only part 
of the routing information, one or more sub¬ 
sequent address messages (SAM) are sent 
containing the remaining information. 

Through connection of the transmission 
path is generally completed in the backward 
direction at the originating exchange immedi¬ 
ately after the sending of the initial address 
message, so that tones and announcements can 
be received by the calling user, if appropriate. 

When the originating exchange has sent the 
initial address message, an awaiting-address- 
complete timer is started, in anticipation of a 
backward message, a number of responses are 
possible: 

(a) If the originating exchange receives an 
address complete message, the awaiting- 
address-complete timer is stopped and an 
awaiting-answer timer is started. Ringing tone 
is applied at the destination exchange (if 
appropriate) and sent to the calling user. 

( b ) If the originating exchange receives a 
call progress message (CPM), this indicates 
that no state change should occur. The infor¬ 
mation carried in the access transport par¬ 
ameter should be sent to the calling user if 
this is an ISDN terminal. 

(c) If an answer message is received indi¬ 
cating that the required connection has been 
completed, the transmission path is connected 
through in the forward direction (if not 
already connected). The awaiting-answer 
timer is stopped. If the originating exchange 
is the controlling node, charging begins, if 
applicable. 

\d) If, however, a connect message is 
received, which indicates a composite address 
complete and answer message, then the 
awaiting-address-complete timer is stopped, 
the transmission path is completed and the 
call is regarded as being in the answer/data 
phase, and charging commences. 
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Call Handling Actions at an Intermediate 
Exchange 

An intermediate exchange, on receipt of an 
initial address message, analyses the called 
user number and the other information to 
determine the routing of the call. If the inter¬ 
mediate exchange can route the call by using 
the connection type specified in the trans¬ 
mission medium requirement parameter, a 
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free inter-exchange circuit is seized and an 
initial address message is sent to the suc¬ 
ceeding exchange. 

Within a network, if the intermediate exch¬ 
ange cannot route the call by using just the 
connection type specified in the transmission 
medium requirement parameter, the exchange 
will also examine the user service information 
(if available) to determine if a suitable route 
can be selected. In this case, if a new connec¬ 
tion type is provided, the transmission medium 
requirement parameter may be modified to a 
new connection type. 

For calls between different networks, the 
gateway exchange (for example, outgoing 
international switching centre) ensures that 
the transmission medium requirement par¬ 
ameter is set according to the service 
requested by the customer, and this parameter 
is then carried unchanged within the inter¬ 
national network. 

An intermediate exchange may modify sig¬ 
nalling information received from the pre¬ 
ceding exchange according to the capabilities 
used on the outgoing route. Signalling infor¬ 
mation that may be changed are the nature 
of connection indicator, end-to-end method 
indicator, the most significant digits in the 
called user number (these may be amended 
or omitted), and a change of the end-to-end 
method used. Other signalling information 
is passed on transparently; for example, the 
access transport parameter, user service infor¬ 
mation etc. 

Through connection of the transmission 
path is generally completed in both directions 
at an intermediate exchange immediately 
after the initial address message has been 
sent. 

Call Handling Actions at the Destination 
Exchange 

On receipt of an initial address message, a 
number of checks are generally performed on 
the called user’s line to determine if the call 
can be allowed; in the case of ISDN terminals, 
this includes compatibility and service 
marking checks. In some cases, additional 
information may be needed to be obtained 
from the originating or controlling exchange; 
for example, calling line identity. Examin¬ 
ation of the protocol control indicator shows 
whether end-to-end information is necessary 
before further processing of the call can take 
place. If so, one of the end-to-end signalling 
methods may be used; namely, SCCP, pass- 
along , or information request and infor¬ 
mation messages. 

If the connection is allowed, the destination 
exchange sets up a connection to the called 
user. 

Sending of an Address Complete Message/ 
Call Progress Message from the Destination 
Exchange 

An address complete message (ACM) is sent 


from the destination exchange under one of 
the following conditions: 

(a) as soon as it has been determined that 
the complete called-user number has been 
received, for example, where the called user 
is a PSTN number; 

( b ) if tones or announcements are applied, 
for example, ringing tone; 

(c) an alerting or call proceeding message 
is received from an ISDN terminal; or 

(d) an indication is received from the called 
user (for example, from an ISPBX) that an 
inband tone is being connected. 

An awaiting answer indication (for 
example, ring tone) is applied at the desti¬ 
nation exchange on speech and 3 • 1 kHz calls 
on the transmission path to the calling user. 

If an ACM has been sent when the called 
user answers, the destination exchange con¬ 
nects through the transmission path and the 
ringing tone is removed (if applicable); an 
answer message is sent to the preceding ex¬ 
change. 

In addition to the procedure detailed above, 
a call progress message (CPM) may also be 
sent, either before or after an ACM, indi¬ 
cating that an event has occurred during call 
set-up which should be relayed to the calling 
user. For example: 

(i a) an indication is received that the called 
user is being alerted, or 

(b) a progress indication is received from 
the called user. 


Sending of an Connect/Answer Message 
from the Destination Exchange 

If a connect indication is the first response 
from an ISDN terminal and an ACM has not 
yet been returned, a connect message is sent 
to the originating exchange. The connect 
message signifies both address complete and 
answer conditions. 


UNSUCCESSFUL CALL SET-UP AND 
RELEASE PROCEDURES 

If at any time during call set-up the connection 
cannot be completed, a release message (con¬ 
taining a ‘reason’ indicating the cause of the 
call failure) is returned, and the release pro¬ 
cedure is then commenced. 

The release procedure is based on a two 
message interchange ( release , release com¬ 
plete) whereby the release message initiates 
release of the circuit-switched connection. 

The same procedure is used in the network 
irrespective of whether it is initiated by the 
calling user, the called user or the network. 
Charging is stopped upon receipt of the 
release message. 
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OTHER PROCEDURES ASSOCIATED 
WITH CALL ESTABLISHMENT 

Information Messages 

Information messages (information request / 
information) can be used typically in associ¬ 
ation with supplementary services; for 
example, obtaining the calling line identity 
(CLI) if not contained in an IAM. In this 
case, an information request message would 
be sent to any exchange in the backward 
direction requesting the CLI. After sending 
an information request message, a timer is 
started. (No second information request 
message may be sent in the same direction 
until a response information message is 
received.) 

An outgoing distant exchange would 
respond with an information message as fol¬ 
lows: 

(a) If all the information requested is avail¬ 
able, an information message containing all 
the required information is sent in response. 

( b ) If all the information is not available, 
then an information message containing only 
the available information is sent. 

The information request/information 
message interchange is a general procedure 
which can be used for a number of different 
services. 


Sending Unsolicited Information 

In addition to the procedure defined above, if 
information is available at an exchange and 
this does not correspond to information which 
has been requested by an information request 
message, this can be sent in the information 
message with the solicited information indi¬ 
cator set to signify that the message has been 
sent unsolicited. 

The unsolicited information message can 
be used only if the ISUP has been used all 
the way. It can be sent in any direction in 
any call state except in the awaiting release 
complete state. 


Suspend and Resume Procedures 

The suspend procedure allows a user (typi¬ 
cally an ISDN terminal) to temporarily sus¬ 
pend the communication without releasing 
the call. It can only be accepted during the 
conversation/data phase. A suspend message 
is used and can be either generated in response 
to a suspend request from the calling/called 
user or generated by the network in response 
to clearback or on hook condition, respect¬ 
ively, from an interworking node. 

A resume procedure is used when a user 
wishes to recommence communication. A 
resume message is used for this purpose. 


Note: a request to release the call received 
from the calling or called user will override 
these procedures. 


In-Call Modification 

For certain types of connection, it is possible 
during the call to change the mode of the 
connection; for example, from speech to data. 
To provide this type of capability, it is required 
at the start of the call to know whether the call 
is an alternate speech/64 kbit/s unrestricted 
call request or vice versa. During call set¬ 
up, the network chooses a suitable route (for 
example, 64 kbit/s and CCITT No. 7 ISUP 
signalling) according to information included 
in the initial address message. 


Other Procedures Incorporated in the 
ISUP 

Q supervision procedures to remove circuits 
or groups of circuits from service to permit 
testing etc., 

• compatibility procedures for the receipt of 
unrecognised messages and parameters, and 
€) procedures for congestion control; for 
example, when an exchange goes into over¬ 
load. 

SIGNALLING METHODS 

The ISUP has two methods available for 
ISDN end-to-end signalling: 

(i a ) the pass-along method; and 

(b) the signalling connection control part 
(SCCP) method. 

The choice of method depends, to some 
extent, on the size and architecture of the 
signalling network. Both methods may coexist 
in a given network. 

The pass-along method and the SCCP 
method are specified for circuit-switched con¬ 
nections. 

In the pass-along method, use is made of 
an ISUP end-to-end signalling connection 
which, in fact, is being set up whenever a 
physical connection between two end points is 
established. 

The pass-along method defines, section by 
section, the appropriate routing label for the 
message to be passed along via ISUP connec¬ 
tions. The content of pass-along messages is 
only evaluated and possibly changed at the 
end points. The pass-along message group is 
characterised by a special message type code. 

The SCCP method employs the services of 
the signalling connection control part for the 
transfer of end-to-end signalling information. 
A companion article describes the SCCP pro¬ 
cedures [2]. 
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SUMMARY 

The ISDN user part has undergone consider¬ 
able revision since its first publication in the 
1984 CCITT Red Book (Recommendations 
Q.761-764). The ISUP is designed basically 
to support ISDN services using the 64 kbit/s 
switched telephony network. Its use for other 
applications such as the support of packet 
and broadband services will be the subject of 
discussions in the next CCITT Plenary Period 
1988-1992. The way the ISDN user part 
evolves in the near future will be crucial to all 
modern telecommunication network develop¬ 
ments as it is this component part of CCITT 
No. 7 signalling that must give the flexibility 
and durability to support the wide range of 
services and facilities required by customers 
and network providers in the future. 
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APPENDIX 1 

FORMATS AND CODES 

The signalling information field of each ISUP 
message consists of an integral number of octets 
and encompasses the following parts (see Figure 
3). 

(a) routing label 

( b) circuit identification code 

(c) message type code 

(i d) mandatory fixed part 
(e) mandatory variable part 
(/) the optional part, which may contain 
fixed-length and variable-length parameter 
fields. 



Figure 3—ISDN user part message structure 


A description of the various message parts is 
given in the following sections. 

Routing Label 

For each individual circuit connection, the same 
routing label must be used for each message 
that is transmitted for that connection. 

Circuit Identification Code 

The format of the circuit identification code 
(CIC) is shown in Figure 4. 
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1 

(least significant bits) 



CIC 

2 

Spare 

(most significant bits) 


The allocation of circuit identification codes 
to individual circuits is by bilateral agreement 
and/or in accordance with predetermined 
rules. 

Allocations for certain applications are 
defined below: 

(a) 2048 kbit/s digital path For circuits 
which are derived from a 2048 kbit/s digital 
path, the circuit identification code contains, 
in the five least significant bits, a binary rep¬ 
resentation of the actual number of the time- 
slot which is assigned to the communication 
path. 

( b) 8448 kbit/s digital path For circuits 
which are derived from a 8448 kbit/s digital 
path, the circuit identification code contains, 
in the seven least significant bits, an identifi¬ 
cation of the circuit (see Table 1). 


TABLE 1 

Circuit Identification Codes 


0 

0 

0 

0 

0 

0 

0 

circuit 1 

0 

0 

0 

0 

0 

0 

1 

circuit 2 

0 

0 

1 

i 

1 

1 

1 

circuit 32 

0 

1 

0 

0 

0 

0 

0 

circuit 33 

1 

1 

1 

i 

1 

1 

0 

circuit 127 

1 

1 

1 

i 

1 

1 

1 

circuit 128 


The remaining bits in the circuit identifi¬ 
cation code are used, where necessary, to 
identify these circuits uniquely among all 
other circuits of other systems interconnecting 
an originating and destination point. 

Message Type Code 

The message type code consists of a one octet 
field and is mandatory for all messages. The 


Figure 4 

Circuit identification 
field 
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message type code uniquely defines the function 
and format of each ISUP message. 

Formatting Principles 

Each message consists of a number of par¬ 
ameters. Each parameter has a name, which is 
coded as a single octet. The length of a par¬ 
ameter may be fixed or variable, and a length 
indicator of one octet for each parameter may 
be included as described below. 

A general format diagram is shown in 
Figure 5. 


Figure 5 

General format of 
signalling information 
field 


Order of bit transmission 



then this pointer is not present. If the message 
type indicates that an optional part is possible, 
but there is no optional part included in this 
particular message then a pointer field con¬ 
taining all zeros is used. All the pointers 
are sent consecutively at the beginning of the 
mandatory variable part. Each parameter con¬ 
tains the parameter length indicator followed by 
the contents of the parameters. 

Optional Part 

The optional part consists of parameters that 
may or may not occur in any particular message 
type. Both fixed-length and variable-length par¬ 
ameters may be included. Optional parameters 
may be transmitted in any order. Each optional 
parameter includes the parameter name (one 
octet) and the length indicator (one octet) fol¬ 
lowed by the parameter contents. 

End of Optional Parameters Octet 

If optional parameters are present and after all 
optional parameters have been sent, an ‘end of 
optional parameters’ octet containing all zeros 
is transmitted. 

Order of Transmission 

Since all the fields consist of an integral number 
of octets, the formats are presented as a stack 
of octets. The first octet transmitted is the one 
shown at the top of the stack and the last is the 
one at the bottom (see Figure 5). 

Within each octet and subfield, the bits are 
transmitted with the least significant bit first. 

ISDN User Part Message Types and Par¬ 
ameters 

The message set used in ISUP and the range of 
parameters which may be used within each of 
the messages are shown in Table 2. 

ISDN User Part Parameters 

The parameter names are given in Table 3. 


Mandatory Fixed Part 

Those parameters that are mandatory and of 
fixed length for a particular message type are 
contained in the mandatory fixed part. The 
position, length and order of the parameters are 
uniquely defined by the message type; thus the 
names of the parameters and the length indi¬ 
cators are not included in the message. 

Mandatory Variable Part 

Mandatory parameters of variable length are 
included in the mandatory variable part. Poin¬ 
ters are used to indicate the beginning of each 
parameter. Each pointer is encoded as a single 
octet. The name of each parameter and the order 
in which the pointers are sent are implicit in the 
message type. Parameter names are, therefore, 
not included in the message. The number of 
parameters, and thus the number of pointers is 
uniquely defined by the message type. 

A pointer is also included to indicate the 
beginning of the optional part. If the message 
type indicates that no optional part is allowed, 


APPENDIX 2 

GENERAL FUNCTION OF MESSAGES 

Signalling Messages Used in the ISDN 
User Part 

Address Complete Message (ACM) 

A message sent in the backward direction indi¬ 
cating that all the address signals required for 
routing the call to the called party have been 
received. 

Answer Message (ANM) 

A message sent in the backward direction indi¬ 
cating that the call has been answered. In semi¬ 
automatic working this message has a super¬ 
visory function. In automatic working this 
message is used in conjunction with charging 
information in order to: 

(a) start metering the charge to the calling 
customer, and 

( b) start measurement of call duration for 
international accounting purposes. 
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TABLE 2 
Message Type 


TABLE 3 

Parameter Name 


Address complete 

Answer 

Blocking 

Blocking acknowledgement 

Call modification completed 

Call modification requested 

Call modification reject 

Call progress 

Circuit group blocking 

Circuit group blocking acknowledgement 

Circuit group query 

Circuit group query response 

Circuit group reset 

Circuit group reset acknowledgement 

Charge information (national use) 

Confusion 

Connect 

Continuity 

Continuity check request 
Delayed release (national use) 

Facility accepted 
Facility reject 
Facility request 
Forward transfer 
Information 
Information request 
Initial address 

Loop back acknowledgement (national use) 
Overload (national use) 

Pass-along 

Release 

Release complete 
Reset circuit 
Resume 

Subsequent address 

Suspend 

Unblocking 

Unblocking acknowledgement 
Unequipped CIC (national use) 
User-to-user information 


Blocking Message (BLO) 

A message sent only for maintenance purposes 
to the exchange at the other end of a circuit, to 
cause an engaged condition of that circuit for 
subsequent calls outgoing from that exchange. 
When a circuit is used in the bothway mode of 
operation, an exchange receiving the blocking 
message must be capable of accepting incoming 
calls on the concerned circuit unless it has also 
sent a blocking message. Under certain con¬ 
ditions, a blocking message is also a proper 
response to a reset circuit message. 

Blocking Acknowledgement Message (BLA) 

A message sent in response to a blocking 
message indicating that the circuit has been 
blocked. 

Call Modification Completed Message (CMC) 

A message sent in response to a call modification 
request message indicating that the requested 
call modification (for example, from voice to 
data) has been completed. 

Call Modification Reject Message (CMRJ) 

A message sent in response to a call modification 


Access transport 
Automatic congestion level 
Backward call indicators 
Call modification indicators 
Call reference 
Called party number 
Calling party number 
Calling party’s category 
Cause indicators 

Circuit group supervision message type 
indicator 

Circuit state indicator 
Closed user group interlock code 
Connected number 
Connection request 
Continuity indicators 
End of optional parameters 
Event information 
Facility indicator 
Forward call indicators 
Information indicators 
Information request indicators 
Nature of connection indicators 
Optional backward call indicators 
Optional forward call indicators 
Original called number 
Range and status 
Redirecting number 
Redirection number 
Redirection information 
Signalling point code (Note 1) 
Subsequent number 
Suspend/Resume indicators 
Transit network selection (Note 1) 
Transmission medium requirement 
User service information 
User-to-user indicators 
User-to-user information 


Note 1 : For national user only 


request message indicating that the request has 
been rejected. 

Call Modification Request Message (CMR) 

A message sent in either direction indicating a 
calling or called party request to modify the 
characteristics of an established call (for 
example, change from data to voice). 

Call Progress Message (CPG) 

A message sent in the backward direction indi¬ 
cation that an event has occurred during call 
set-up which should be relayed to the calling 
party. 

Circuit Group Blocking Message (CGB) 

A message sent to the exchange at the other end 
of an identified group of circuits to cause an 
engaged condition of this group of circuits for 
subsequent calls outgoing from that exchange. 
An exchange receiving a circuit group blocking 
message must be able to accept incoming calls 
on the group of blocked circuits unless it has 
also sent a blocking message. Under certain 
conditions, a circuit group blocking message is 
also a proper response to a reset circuit message. 
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Circuit Group Blocking Acknowledgement 
Message (CGBA) 

A message sent in response to a circuit group 
blocking message to indicate that the requested 
group of circuits has been blocked. 

Circuit Group Reset Message (GRS) 

A message sent to release an identified group of 
circuits when, due to memory mutilation or 
other causes, it is unknown whether for example, 
a release or release complete message is appro¬ 
priate for each of the circuits in the group. If at 
the receiving end, a circuit is remotely blocked, 
reception of this message should cause that con¬ 
dition to be removed. 

Circuit Group Reset Acknowledgement 
Message (GRA) 

A message sent in response to a circuit group 
reset message and indicating that the requested 
group of circuits has been reset. The message 
also indicates the maintenance blocking state of 
each circuit. 

Circuit Group Unblocking Message (CGU) 

A message sent to the exchange at the other 
end of an identified group of circuits to cause 
cancellation in that group of circuits of an 
engaged condition invoked earlier by a blocking 
or circuit group blocking message. 

Circuit Group Unblocking Acknowledgement 
Message (CGUA) 

A message sent in response to a circuit group 
unblocking message to indicate that the 
requested group of circuits has been unblocked. 

Circuit Group Query Message (CQM) 

A message sent on a routine or demand basis to 
request the far-end exchange to give the state 
of all circuits in a particular range. 

Circuit Group Query Response Message 
(CQR) 

A message sent in response to a circuit group 
query message to indicate the state of all circuits 
in a particular range. 

Confusion Message (CFN) 

A message sent in response to any message 
(other than a confusion message) if the exchange 
does not recognise the message or detects a part 
of the message as being unrecognised. 

Connect Message (CON) 

A message sent in the backward direction indi¬ 
cating that all the address signals required for 
routing the call to the called party have been 
received and that the call has been answered. 

Continuity Message (COT) 

A message sent in the forward direction indi¬ 
cating whether or not there is continuity on the 
preceding circuit(s) as well as on the selected 
circuit to the following exchange, including veri¬ 
fication of the communication path across the 
exchange with the specified degree of reliability. 


Continuity Check Request Message (CCR) 

A message sent by an exchange for a circuit on 
which a continuity check is to be performed, to 
the exchange at the other end of the circuit, 
requesting continuity checking equipment to be 
attached. 

Delayed Release Message (DRS) (National 
Use) 

A message sent in either direction indicating 
that the called or calling party has disconnected, 
but that the network is holding the connection. 

Facility Accepted Message (FAA) 

A message sent in response to a facility request 
message indicating that the requested facility 
has been invoked. 

Facility Reject Message (FRJ) 

A message sent in response to a facility request 
message to indicate that the facility request has 
been rejected. 

Facility Request Message (FAR) 

A message sent from an exchange to another 
exchange to request activation of a facility. 

Forward Transfer Message (FOT) 

A message sent in the forward direction on semi¬ 
automatic calls when the outgoing international 
exchange operator wants the help of an operator 
at the incoming international exchange. The 
message normally serves to bring an assistance 
operator into the circuit if the call is automati¬ 
cally set up at the exchange. When the call is 
completed via an operator (incoming or delay 
operator) at the incoming international exch¬ 
ange, the message should preferably cause this 
operator to be recalled. 

Information Message (INF) 

A message is sent to convey information in 
association with a call, which may have been 
requested in an information request message. 

Information Request Message (INR) 

A message sent by an exchange to request infor¬ 
mation in association with a call. 

Initial Address Message (1AM) 

A message sent in the forward direction to 
initiate seizure of an outgoing circuit and to 
transmit number and other information relating 
to the routing and handling of a call. 

Loop Back Acknowledgement Message 
(LPA) (National Use) 

A message sent in the backward direction in 
response to a continuity check request message 
indicating that a loop (or transceiver in the case 
of a 2-wire circuit) has been connected. 

Overload Message (OLM) (National Use) 

A message sent in the backward direction, on 
non-priority calls in response to an IAM, to 
invoke temporary trunk blocking of the circuit 
concerned when the exchange generating the 
message is subject to load control. 


British Telecommunications Engineering , Vol. 7, April 1988 


53 




Pass-Along Message (PAM) 

A message that may be sent in either direction 
to transfer information between two signalling 
points along the same signalling path as that 
used to establish a physical connection between 
those two points. 

Release Message (REL) 

A message sent in either direction, to indicate 
that the circuit is being released because of the 
reason (cause) supplied and is ready to be put 
into the idle state on receipt of the release 
complete message. In case the call was for¬ 
warded or is to be re-routed, the appropriate 
indicator is carried in the message together with 
the redirection address and the redirecting 
address. 

Release Complete Message (RLC) 

A message sent in either direction in response 
to the receipt of a release message, or if appro¬ 
priate, to a reset circuit message, when the 
circuit concerned has been brought into the idle 
condition. 

Reset Circuit Message (RSC) 

A message sent to release a circuit when, because 
of memory mutilation or other causes, it is 
unknown whether, for example, a release or a 
release complete message is appropriate. If at 
the receiving end the circuit is remotely blocked, 
reception of this message should cause that con¬ 
dition to be removed. 

Resume Message (RES) 

A message sent in either direction indicating 
that the calling or called party, after having 
been suspended, is reconnected. 

Subsequent Address Message (SAM) 

A message that may be sent in the forward 
direction after an initial address message, to 
convey additional called party number infor¬ 
mation. 

Suspend Message (SUS) 

A message sent in either direction indicating that 
the calling or called party has been temporarily 
disconnected. 

Unblocking Message (UBL) 

A message sent to the exchange at the other end 
of a circuit to cancel, at that exchange, the 
engaged condition of the circuit caused by a 
previously sent blocking or circuit group 
blocking message. 

Unblocking Acknowledgement Message 
(UBA) 

A message sent in response to an unblocking 
message indicating that the circuit has been 
unblocked. 

Unequipped Circuit Identification Code 
Message (UCIC) (National Use) 

A message sent from one exchange to another 
when it receives an unequipped circuit identifi¬ 
cation code. 


User-to-User Information Message (USR) 

A message to be used for the transport of user- 
to-user signalling independent of call-control 
messages. 


APPENDIX 3 

SIGNALLING INFORMATION PAR¬ 
AMETERS 

Access Transport 

Information generated on the access side of 
a call and transferred transparently in either 
direction between originating and terminating 
local exchanges. The information is significant 
to both users and local exchanges. 

Address Presentation Restricted Indicator 

Information sent in either direction to indicate 
that the address information is not to be pre¬ 
sented to a public network user, but can be 
passed to another public network. It may also 
be used to indicate that the address cannot be 
ascertained. 

Address Signal 

An element of information in a network number. 
The address signal may indicate digit values 0 
to 9, code 11 or code 12. One address signal 
value (ST) is reserved to indicate the end of the 
called party number. 

Automatic Congestion Level 

Information sent to the exchange at the other 
end of a circuit to indicate that a particular level 
of congestion exists at the sending exchange. 

Call Forwarding Indicator 

Information sent in the backward direction indi¬ 
cating that call forwarding may occur, 
depending on the response received (or lack 
thereof) from the called party. 

Call Identity 

Information sent in the call reference parameter 
indicating the identity of a call in a signalling 
point. 

Call Reference 

Circuit independent information identifying a 
particular call. 

Called Party Number 

Information to identify the called party. 

Called Party's Category Indicator 

Information sent in the backward direction indi¬ 
cating the category of the called party; for 
example, ordinary customer or payphone. 

Called Party's Status Indicator 

Information sent in the backward direction indi¬ 
cating the status of the called party; for example, 
customer free. 
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Calling Party Number 

Information sent in the forward direction to 
identify the calling party. 

Calling Party Address Request Indicator 

Information sent in the backward direction indi¬ 
cating a request for the. calling party address to 
be returned. 

Calling Party Address Response Indicator 

Information sent in response to a request for the 
calling party address, indicating whether the 
requested address is included, not included, not 
available or incomplete. 

Calling Party Number Incomplete Indicator 

Information sent in the forward direction indi¬ 
cating that the complete calling party number 
is not included. 

Calling Party's Category Indicator 

Information sent in the forward direction indi¬ 
cating the category of the calling party and, in 
case of semi-automatic calls, the service lan¬ 
guage to be spoken by the incoming, delay and 
assistance operators. 

Calling Party's Category Request Indicator 

Information sent in the backward direction indi¬ 
cating a request for the calling party’s category 
to be returned. 

Calling Party's Category Response Indicator 

Information sent in response to a request for the 
calling party’s category indicating whether or 
not the requested information is included in the 
response. 

Circuit Identification Code 

Information identifying the physical path 
between a pair of exchanges. 

Circuit State Indicator 

Information indicating the state of a circuit 
according to the sending exchange. 

Closed User Group Call Indicator 

Information indicating whether or not the con¬ 
cerned call can be set up as a closed user group 
call and, if a closed user group call, whether or 
not outgoing access is allowed. 

Closed User Group Interlock Code 

Information uniquely identifying a closed user 
group within a network. 

Coding Standard 

Information sent in association with a parameter 
(for example, cause indications) identifying the 
standard in which the parameter format is 
described. 

Connected Number 

Information sent in the backward direction to 
identify the connected party. 


Connection Request 

Information sent in the forward direction on 
behalf of the signalling connection control part 
requesting the establishment of an end-to-end 
connection. 

Continuity Check Indicator 

Information sent in the forward direction indi¬ 
cating whether or not a continuity check will be 
performed on the circuit(s) concerned or is being 
(has been) performed on a previous circuit in 
the connection. 

Continuity Indicator 

Information sent in the forward direction indi¬ 
cating whether or not the continuity check on 
the outgoing circuit was successful. A continuity 
check successful indication also implies conti¬ 
nuity of the preceding circuits and successful 
verification of the path across the exchange with 
the specified degree of reliability. 

Credit 

Information sent in a connection request , indi¬ 
cating the window size requested by the signal¬ 
ling connection control part for an end-to-end 
connection. 

Diagnostic 

Information sent in association with a cause 
value and which provides supplementary infor¬ 
mation about the reason for sending the 
message. 

Echo Control Device Indicator 

Information indicating whether or not a half 
echo control device is included in the connection. 

End-to-End Information Indicator 

Information sent in either direction indicating 
whether or not the sending exchange has further 
call information available for end-to-end trans¬ 
mission. In the forward direction, an indication 
that end-to-end information is available implies 
that the destination exchange may obtain the 
information before alerting the called party. 

End-to-End Method Indicator 

Information sent in either direction indicating 
the available methods, if any, for end-to-end 
transfer of information. 

Event Indicator 

Information sent in the backward direction indi¬ 
cating the type of event which caused a call 
progress message to be sent to the originating 
local exchange. 

Event Presentation Restricted Indicator 

Information sent in the backward direction indi¬ 
cating that the event should not be presented to 
the calling party. 

Extension Indicator 

Information indicating whether or not the 
associated octet has been extended. 
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Facility Indicator 

Information sent in facility-related messages 
identifying the facility or facilities with which 
the message is concerned. 

Holding Indicator (National Use) 

Information sent in either direction indicating 
that holding of the connection is requested. 

Hold Provided Indicator (National Use) 

Information sent in either direction indicating 
that the connection will be held after the calling 
or called party has attempted to release. 

In-band Information Indicator 

Information sent in the backward direction indi¬ 
cating that in-band information or an appro¬ 
priate pattern is now available. 

Internal Network Number Indicator 

Information sent to the destination exchange 
indicating whether or not the call is allowed 
should the called party number prove to be an 
internal network number (for example, mobile 
access point). 

Interworking Indicator 

Information sent in either direction indicating 
whether or not CCITT No. 7 signalling is used 
in all parts of the network connection. 

ISDN User Part Indicator 

Information sent in either direction to indicate 
that the ISUP is used in all parts of the network 
connection. 

ISDN User Part Preference Indicator 

Information sent in the forward direction indi¬ 
cating whether or not the ISUP is required or 
preferred in all parts of the network connection. 

Local Reference 

Information sent in the connection request , indi¬ 
cating the local reference allocated by the signal¬ 
ling connection control part to an end-to-end 
connection. 

Location 

Information sent in either direction indicating 
where an event (for example, release) was gener¬ 
ated. 

Malicious Call Identification Request Indi¬ 
cator (National Use) 

Information sent in the backward direction to 
request the identity of the calling party for the 
purpose of malicious call identification. 

Modification Indicator 

Information sent in the call modification indi¬ 
cators parameter indication whether the call 
modification is to service 1 or service 2. 

National/International Call Indicator 

Information sent in the forward direction indi¬ 
cating in the destination national network 


whether the call has to be treated as an inter¬ 
national call or as a national call. 

Nature of Address Indicator 

Information sent in association with an address 
indicating the nature of that address; for 
example, ISDN international number, ISDN 
national significant number, or ISDN customer 
number. 

Numbering Plan Indicator 

Information sent in association with a number 
indicating the numbering plan used for that 
number (for example, ISDN number, Telex 
number). 

Odd/Even Indicator 

Information sent in association with an address, 
indicating whether the number of address signals 
contained in the address is even or odd. 

Original Called Number 

Information sent in the forward direction when 
a call is redirected more than once and identifies 
the original called party. 

Original Redirection Indicator 

Information sent in either direction indicating, 
in the case of calls undergoing multiple redirec¬ 
tions, whether the call was forwarded or re¬ 
routed, and whether presentation of the original 
redirection information to the calling party is 
restricted. 

Original Redirection Reason 

Information sent in either direction indicating, 
in the case of calls undergoing multiple redirec¬ 
tions, the reason why the call was originally 
redirected. 

Point Code 

Information sent in the call reference parameter 
indicating the code of the signalling point in 
which the call identity allocated to the call 
reference is relevant. 

Protocol Class 

Information sent in the connection request par¬ 
ameter indicating the protocol class requested 
by the signalling connection control part for the 
end-to-end connection. 

Protocol Control Indicator 

Information consisting of the end-to-end method 
indicator, the interworking indicator, the end- 
to-end information indicator, the SCCP method 
indicator and the ISUP indicator. The protocol 
control indicator is contained in both the forward 
and backward call indicators parameter field 
and describes the signalling capabilities within 
the network connection. 

Range 

Information sent in a circuit group supervision 
message (for example, circuit group blocking) 
to indicate the range of circuits affected by the 
action in the message. 


56 


British Telecommunications Engineering , Vol. 7, April 1988 


Recommendation Indicator 

Information sent in association with a cause 
value identifying the Recommendation to which 
the cause value applies. 

Redirecting Indicator 

Information sent in either direction indicating 
whether the call has been forwarded or re-routed 
and whether or not presentation of redirection 
information to the calling party is restricted. 

Redirecting Number 

Information sent in the forward direction indi¬ 
cating the number from which the call was last 
redirected. 

Redirecting Reason 

Information sent in either direction indicating 
the reason why the call has been redirected. 

Redirection Counter 

Information sent in either direction indicating 
the number of redirections which have occurred 
on a call. 

Redirection Number 

Information sent in the backward direction indi¬ 
cating the number towards which the call must 
be re-routed or has been forwarded. 

Routing Label 

Information provided to the message transfer 
part for the purpose of message routing. 

Satellite Indicator 

Information sent in the forward direction indi¬ 
cating the number of satellite circuits in the 
connection. 

SCCP Method Indicator 

Information sent in either direction indicating 
the available SCCP methods, if any, for end-to- 
end transfer of information. 

Screening Indicator 

Information sent in either direction to indicate 
whether the address was provided by the user 
or network. 

Signalling Point Code (National Use) 

Information sent in a release message to identify 
the signalling point in which the call failed. 

Solicited Information Indicator 

Information sent in an information message to 
indicate whether or not the message is a response 
to an information request message. 


Status 

Information sent in a circuit group supervision 
message (for example, circuit group blocking) 
to indicate the specific circuits, within the range 
of circuits stated in the message, that are 
affected by the action specified in the message. 

Suspend/Resume Indicator 

Information sent in the suspend and resume 
messages to indicate whether suspend/resume 
was initiated by an ISDN customer or by the 
network. 

Temporary Trunk Blocking After Release 
(National Use) 

Information sent to the exchange at the other 
end of a circuit (trunk) to indicate low level of 
congestion at the sending exchange and that the 
circuit (trunk) should not be re-occupied by the 
receiving exchange for a short period of time 
after release. 

Transit Network Selection (National Use) 

Information sent in the initial address message 
indicating the transit network(s) requested to be 
used in the call. 

Transmission Medium Requirement 

Information sent in the forward direction indi¬ 
cation the type of transmission medium required 
for the connection (for example, 64 kbit/s unre¬ 
stricted, speech etc.). 

User Service Information 

Information sent in the forward direction indi¬ 
cating the bearer capability requested by the 
calling party. 

User-to-User Indicators 

Information sent in association with a request 
(or response to a request) for user-to-user signal¬ 
ling supplementary service(s) 

User-to-User Information 

Information generated by a user and transferred 
transparently through the inter-exchange net¬ 
work between the originating and terminating 
local exchanges. 
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Transaction capabilities (TC) is the CCITT Signalling System No. 7 protocol used, in conjunction 
with the signalling connection control part and the message transfer part, to convey non-circuit- 
related information between signalling nodes. This article gives an outline description of TC and 
identifies the need for such a protocol, the functions within the TC protocol and how it may be used 
by services; in particular, two examples of its use are described: in the support of mobile services, 
and operations and maintenance. 


INTRODUCTION 

Today’s telecommunications customers have 
come to expect and demand more than a basic 
telephone service. With the advent of mobile 
telephones and the services offered by modern 
digital PABXs, it will not be long before 
customers demand similar services from the 
public switched telephone network (PSTN). 
For these advanced services, the signalling 
information must not be restricted to a tel¬ 
ephony circuit, and therefore a non-circuit- 
related signalling protocol is required. Simi¬ 
larly, the management of complex digital net¬ 
works requires fast, flexible and reliable com¬ 
munication such as that offered by a non- 
circuit-related CCITT signalling system pro¬ 
tocol. 

Rather than define its own non-circuit 
related signalling protocol, British Telecom is 
contributing significantly to a CCITT-speci- 
fied Signalling System No. 7 non-circuit- 
related protocol known as transaction capa¬ 
bilities (TC). The first CCITT TC Rec¬ 
ommendation will be available later in 1988 
as Q.771-Q.774. 

Unlike the message transfer part (MTP) 
and the national user part (NUP) which are 
currently implemented within the PSTN, TC 
is very much at the specification stage. TC is 
intended to complement rather than compete 
with the existing NUP or with data protocols 
such as X.409. 

TRANSACTION CAPABILITIES OVER¬ 
VIEW 

The TC protocol is intended to be used for 
many different applications such as: 

(i a ) mobile network support, 

(b) operations and maintenance, 

(c) network management, 

(d) enhanced supplementary and value- 
added services, and 

(< e ) customer-to-customer data transfer. 


t Network Planning and Works Department, Bri¬ 
tish Telecom UK Communications 



Figure 1 

Transaction capability 
architecture 


To achieve flexibility for a wide number of 
applications, TC has been structured in line 
with the Open Systems Interconnection (OSI) 
7-layer model [1]. (See Figure 1.) 

TC uses the underlying services of the 
MTP [2] and the switching connection control 
part (SCCP) [3] described in other articles in 
this issue of the Journal. In the future, TC 
may be able to use other network services 
such as X.25. 

TC itself has been sub-divided into the 
intermediate service part (ISP) and the trans¬ 
action capabilities application part (TCAP). 
The ISP is required only when large amounts 
of data, possibly over an extended period of 
time, are to be transferred by using an under¬ 
lying connection-orientated protocol as 
described in the article on SCCP. The appli¬ 
cations currently being studied by CCITT 
involve relatively short or time-sensitive mess- 
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ages where it is not practical to set up a 
connection and consequently use an under¬ 
lying connectionless service. For this reason, 
this article concentrates on TCAP rather than 
the ISP. 

TCAP is unlike traditional telephony sig¬ 
nalling protocols and bears some similarity to 
the English language and to expert systems. 
On expert systems, the user sets up a dialogue 
with the system requesting a specific action 
to which the system responds. The response 
might be a request to the user, a result (suc¬ 
cessful or unsuccessful) or an indication that 
the request was not understood. This dialogue 
continues until the problem is resolved. In the 
same way that sentences are made up of 
words, TCAP messages are made up of com¬ 
ponents. Consequently, a large number of 
messages can be created from a relatively 
small number of components. The applica¬ 
tion-specific information within a component, 
and the order of components within a message, 
are defined by the TC user; this allows TCAP 
to be independent of the application. 

STRUCTURE OF TCAP 

To provide control of the dialogue, TCAP is 
divided into two sublayers: the transaction 
sublayer and the component sublayer. 

Transaction Sublayer 

The transaction sublayer is responsible for 
initiating, maintaining and terminating com¬ 
munication between nodes. This communi¬ 
cation or dialogue is known as a transaction ; 
hence the name transaction capabilities. 
Although the contents of a message are appli¬ 
cation dependent, messages are grouped into 
one of four types: 

(a) Begin This message type initiates a 
transaction with a distant node. 

( b ) Continue This message type main¬ 
tains an existing transaction. 

(c) End This message type terminates a 
transaction in normal circumstances. 

( d) Abort This message type ends a 
transaction in abnormal situations. 

In order to correlate messages and allow 
more than one transaction between nodes at 


any one time, each message has at least one 
transaction identity. The transaction identity 
is locally assigned by a node and works in a 
manner similar to references in letter corre¬ 
spondence. The originating transaction 
identity is a reference generated by the node 
sending the message, while the destination 
transaction identity is the node receiving the 
message. 

Table 1 shows the transaction identities 
present in each message type. 


TABLE 1 

Presence of Transaction Identity in TC 
Message Types 


Message Type 

Transaction Identity 

Originating 

Destination 

Begin 

Yes 

No 

Continue 

Yes 

Yes 

End 

No 

Yes 

Abort 

No 

Yes 


All information elements within TC use 
the name, length, value encoding technique. 
Although this increases the size of messages 
and can increase processing overheads, these 
disadvantages are small compared with the 
flexibility offered by the name, length, value 
concept. Taking the originating transaction 
identity as an example, the first field indicates 
that the information element is an originating 
transaction identity, the next field would indi¬ 
cate the number of octets for the value of the 
transaction identity and the value field would 
indicate the originating transaction identity. 
This means that the maximum number of 
transactions a node can perform is not con¬ 
strained by fixed length fields—a problem 
with the NUP, which has a 12 bit circuit 
identification code field. 

After the transaction identities in the begin , 
continue and end message types is another 
information element known as the component 
portion. This information is provided by the 
component sublayer and is carried trans¬ 
parently through the transaction portion (See 
Figure 2). 

The abort message type differs from the 
other message types in that it does not have 
a component portion information element. 


Figure 2 

Transaction portion 
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Instead, it has either a provider abort cause 
or a user abort cause. This depends on whether 
the transaction sublayer aborted the trans¬ 
action, in which case a provider abort cause 
is given, or the user aborted the transaction 
where a user abort cause and optional user 
information is given. 

On a new transaction, the user, via the 
component sublayer, provides the transaction 
sublayer with an originating and destination 
address along with the information to be 
transmitted. The transaction sublayer main¬ 
tains a record of transaction identities and the 
corresponding address for use by the SCCP. 
Similarly, the SCCP may pass TC messages 
to the transaction sublayer, which maintains 
and correlates the transaction identities and 
address information before passing the user 
information to the component sublayer. 

Receipt of an end message from the SCCP 
or an indication from the user terminates the 
transaction. 

Component Sublayer 

The component sublayer is responsible for 
correlating responses to requests and pro¬ 
viding basic error detection. Although the 
information within a component is application 
dependent, components are grouped into one 
of five types: 

(a) invoke ; 

(b) return result — last ; 

(c) return result—not last ; 

( d) return error, ; and 

(ie) reject. 

The invoke component type requests infor¬ 
mation or action by the distant user. So that 
responses can be associated with an invo¬ 
cation, all invoke components contain an 
invoke identity. In some cases an invoke com¬ 
ponent type may be a response to an earlier 
invocation and includes a linked identity 
which associates it with the earlier invocation. 


Invoke component types also contain an oper¬ 
ation code and optional parameters which are 
defined by the TC user (see Figure 3). 

The return result component types not only 
indicate a success but may also contain a 
response or a result. Two return result com¬ 
ponent types allow results to be segmented 
where a single message would exceed the 
underlying message length capability of the 
underlying network layer. The only or last 
response is always sent in a return result—last 
component type. Any intermediate segmented 
response is sent in a return result—not last 
component type. 

The return error component type is used to 
indicate that the associated invocation was 
unsuccessful. The reason the invocation was 
unsuccessful is indicated to the TC user by 
means of an error code and any associated 
parameters. 

A reject component type is used by the 
TC user or by TCAP when information is 
corrupted, mis-sequenced or not understood. 
As this could be detected by either, the 
problem codes are defined within TCAP. 

In some applications, a response to an invo¬ 
cation may not be necessary and it is the 
responsibility of the user to indicate this by 
means of a class. There are four classes corre¬ 
sponding to the four possible combinations of 
the return result and return error component 
types: 

Class 1: Report success or failure Either 
a return result or a return error component 
must be returned. 

Class 2: Report failure A return error 
component is returned if the invocation failed. 

Class 3: Report success A return result 
component is returned if the invocation suc¬ 
ceeded. 

Class 4: Report neither success nor 
failure Neither a return result nor return 
error component is returned. 
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Component portion 
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The component sublayer runs a time-out 
for all four classes. Under normal conditions, 
this time-out never matures for class 1 invoke 
component types. If the time-out does mature 
for class 1, an error condition is detected and 
the user is informed. If the time-out matures 
for classes 2 and 3, the user is informed; 
this implies that the. invocation was either 
successful or unsuccessful, respectively. A 
time-out is run only on class 4 invocations to 
associate a reject component with it. 

The invoke identity is freed when the time¬ 
out matures, a return result—last or a return 
error component type is received. 

The component sublayer receives infor¬ 
mation from the user, packaged in the correct 
component type, and a record of the active 
invoke identities within a transaction is kept. 
The user also indicates the type of message in 
which the components should be transmitted, 
and all associated components are sent in 
this indication to the transaction sublayer. 
Information from the transaction sublayer is 
examined by the component sublayer and all 
valid components passed to the user in the 
order received. 



MS: Mobile station HLR: Home location register 

BS: Base station VLR: Visitor location register 

MSC: Mobile switching centre 

Figure 4—Public land mobile network 



Figure 5—Updating involving both VLR and HLR 


APPLICATIONS 

USE OF TC PROTOCOL BY MOBILE SER¬ 
VICES 

As stated earlier, one use of TCAP is in the 
support of the signalling required for mobile 
services. TCAP is used to support such pro¬ 
cedures as location registration, handover and 
the handling of supplementary services. 

An earlier article in this Journal described 
the Cellnet cellular radio network [4]; how¬ 
ever, for the purposes of this example, a brief 
outline of the mobiles network is given below. 

A public land mobile network may consist 
of four functional entities as shown in 
Figure 4. 

Information about the mobile customer is 
held in a home location register (HLR). The 
visitor location register (VLR) holds the infor¬ 
mation necessary to support the services 
required by a mobile station (MS) when 
roaming in the domain covered by that VLR. 
Whenever a MS roams into a mobile swit¬ 
ching centre (MSC) area covered by a new 
VLR domain, the information required to 
support that MS is copied from the HLR to 
the VLR. 

When a call is made from a PSTN to a 
MS, the local exchange (or transit exchange) 
analyses the mobile service national desti¬ 
nation code dialled. If the number dialled has 
an international prefix, then the call is routed 
directly to an international switching centre, 
otherwise the HLR of the MS is interrogated. 
The HLR returns the roaming number of the 
called MS, to enable the local exchange to 
route the call to the MSC covering the area 
in which the MS is situated. The MSC, in 
turn, interrogates its associated VLR to deter¬ 
mine the correct base station and frequency 
channel for the call. 

For calls made by a mobile customer, the 
signalling information is detected by the base 
station and passed to the nearest MSC. The 
MSC interrogates the VLR before routing the 
call. 

The VLR, HLR and MSC each contain a 
mobile application part (MAP) which holds 
all the operations and associated parameters 
needed to support the procedures required by 
that entity. It is these operations and par¬ 
ameters that are packaged and conveyed by 
TCAP. 

Location Register Updating 

On recognition of a location registration 
request from a MS, the MSC invokes an 
update location area operation, see Figure 5. 
The MAP within the MSC initiates the pro¬ 
cedure by first assigning a dialogue and invoke 
identity to the operation. The dialogue 
identity is mapped to the transaction identity 
by the component sublayer. The invoke 
identity is used by the VLR to correlate its 
reply to the initial invocation. 
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The operation, its parameters and identities 
are passed to and stored in the component 
sublayer until a begin request with the same 
dialogue identity is received. 

On receipt of the begin request from MAP, 
the component sublayer passes the update 
location area operation and associated data 
to the transaction sublayer in a composite 
begin request. A record of the invoke identity 
is kept in the component sublayer to correlate 
return results or return errors. 

The update location area operation is 
implicitly understood as a class 1 invocation 
by both communicating entities; therefore, a 
response (of success or failure) is expected. 

A time-out is started in the component 
sublayer; this gives the time by which an 
indication of success or failure is expected. 
The expiry of this time-out indicates a failure 
in the network. 

The begin message passed to the SCCP by 
the transaction sublayer contains the com¬ 
ponent type, the operation and associated par¬ 
ameters, the transaction identity and the orig¬ 
inating and destination addresses. 

On receipt of the begin message at the 
VLR, the underlying transaction sublayer sets 
up a record and allocates a local transaction 
identity for reference within the VLR. The 
message is then sent to the component 
sublayer. The component sublayer extracts 
and validates the invoke component before 
passing it onto MAP. MAP, in turn, processes 
the update location area operation and associ¬ 
ated parameters. 

If it is found that the VLR has no record 
of the mobile station, information needed to 
support that MS is retrieved from the relevant 
HLR. The VLR therefore opens a transaction 
using a new transaction identity with the 
HLR. The operation is update location using 
an invoke component; associated parameters 
are the international mobile subscriber 
identity and roaming number. 

The HLR in turn responds with return 
result within an end message, and containing 
those parameters necessary to support the 
mobile station. 

The end message closes the transaction 
between the VLR and HLR. 

A return result—last component type is 
sent from the VLR to the MSC in an end 
message. Parameters included in the return 
result—last component type are temporary 
mobile subscriber identity and the signalling 
encryption key. The invoke identity included 
in the return result—last component type is 
that assigned to the original update location 
area request. 

The end message closes the transaction 
between the MSC and the VLR. 


Outgoing Call Set-up 

When a MSC receives an indication from a 
MS requesting call set-up, the MSC transmits 


a send information for outgoing call set-up 
operation to its associated VLR requesting all 
the parameters required for call set-up, see 
Figure 6. The operation is sent in a begin 
message and the TCAP procedure is the same 
as that shown for location register updating. 



MSC VLR 


Begin—invoke 


Send information for outgoing call set up 

End—return result 

Information acknowledge for outgoing call set-up 


Figure 6 
Procedure for 
information retrieval 
for outgoing call set-up 


The VLR responds with an information 
acknowledge for outgoing call set-up result, 
containing those parameters relevant for call 
set-up. The information is sent in an end 
message, which, in turn, closes the trans¬ 
action. The MSC then sets up the call via the 
fixed network. 

Incoming Call Set-up 

For a mobile terminating call, the MSC 
receives, via the fixed network, a connection 
request giving the roaming number of the 
MS. The MSC forwards a begin message 
containing a send information for incoming 
call set-up operation with the MS roaming 
number parameter to its associated VLR, see 
Figure 7. 



MSC VLR 


Begin — invoke 


Send information for incoming call set-up 

End—return result 

Information acknowledge for incoming call set-up 


Figure 7 
Procedure for 
information retrieval 
for incoming call set¬ 
up 


The VLR responds with an end message 
containing an information acknowledge for 
incoming call set-up result having those par¬ 
ameters required for call set-up. The MSC 
then forwards the connection request to the 
MS via the base station by using information 
acquired from the VLR. 

ADMINISTRATIVE USE OF TC PRO¬ 
TOCOL BY OPERATIONS AND MAIN¬ 
TENANCE 

The above example is an illustration of how 
TC is used in the support of a customer 
service. However, the TC protocol, because of 
its generic nature, is not limited to supporting 
customer services. One example of its diversity 
is in its support of network administration. 
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The operations and maintenance appli¬ 
cation part (OMAP) of CCITT No. 7 is speci¬ 
fied in CCITT Recommendation Q.795 and 
contains those procedures and functions 
required to manage the operation and main¬ 
tenance of the signalling system, the signalling 
network, exchanges and other nodes supported 
by the signalling network. In future, it may 
also provide the communications interface for 
the telecommunications management network 
(TMN), and thus enable CCITT No. 7, 
through TC, to provide the data communi¬ 
cations network (DCN) for TMN. 

Operations and Maintenance Procedures 
for the Signalling Network 

This area of OMAP, because of its direct 
impact on the performance of CCITT No. 7, 
has been given the highest priority for specifi¬ 
cation. The activities that have been identified 
are as follows: 

• Management of routing data concerns 
the creation, modification, deletion, interrog¬ 
ation, activation and deactivation of routing 
data at nodes within the CCITT No. 7 net¬ 
work. The activity can be applied to many 
signalling routing relations or to a single sig¬ 
nalling routing relation. The specification of 
the information elements in this function are 
for further study. 

• Circuit validation test (CVT) is to ensure 
that the two exchanges in a signalling relation 
have sufficient and consistent translation data 
in the telephony user part and ISDN user part 
for placing a call on a specific circuit of an 
inter-exchange circuit group. This means in 
practice that the circuit identification code 
and routing label produced from input call 
control data is always consistent with the 
physical circuit that is also identified by the 
input data. 

A CVT may be initiated by either exchange 
on demand or from maintenance and oper¬ 
ating staff by a suitable man-machine inter¬ 
face. The test is performed before any circuit 
continuity test on the initialisation of a circuit 
to ensure that reason for failure of the conti¬ 
nuity test can immediately be attributed to 
the circuit hardware. Similarly, for the CVT 
to give an unambiguous result, it is necessary 
to prove the capability of the supporting mech¬ 
anisms in CCITT No. 7 (the MTP and 
SCCP). This is achieved by the MTP routing 
verification test (MRVT) and the SCCP 
routing verification test (SRVT). 

• MTP routing verification test (MRVT) is 
used to determine whether the data held 
within the MTP routing tables in the CCITT 
No. 7 signalling network is consistent and 
correct. The test enables all possible signalling 
routes within a signalling network from the 
initiating node to the destination node to be 
proved, including an audit of all signalling 
transfer points (STPs) used. This procedure 


is applied only when the underlying MTP 
internal tests have been successfully com¬ 
pleted. 

The test procedure is terminated by any 
node in the test when that node detects an 
error. Should an inconsistency or failure be 
detected, local actions are taken and the 
initiator signalling point (SP) of the test 
alerted. Use is made of the following test 
messages: 

(< a ) MTP routing verification test (RVT) 
is sent from one SP to an adjacent SP. Among 
the information contained in the message is 
the destination node under test, to facilitate 
onward routing; the initiating node and the 
maximum number of STPs which may be 
transmitted by the test. 

( b ) MTP routing verification test acknowl¬ 
edgement (RVA) is returned to the adjacent 
SP which sent the RVT. This indicates test 
success or failure with reason. 

(c) MTP routing verification result (RVR) 
is sent from an SP to the initiating SP to 
indicate the success or failure of the test giving 
the reasons and other data required. When 
sent from an intermediate SP it indicates 
failure; when sent from the test destination it 
indicates success or failure as appropriate. 

The MRVT procedure is initiated manually 
by the local operations and maintenance 
(O & M) system management process 
(SMAP) or automatically on receipt of a 
message for an SP which is unknown or when 
an RVT is received by OMAP at an SP. 
The message flow across the CCITT No. 7 
signalling network generated by the MRVT 
is shown in Figure 8. 

O SCCP routing verification test 
(SRVT) in a manner similar to the MRVT, 
checks the SCCP routing data within the 
CCITT No. 7 signalling network. This also 
results in the proving of all recognised SCCP 
routes from an SP and the verification of 
the global title translation function and data 
within the SCCP. The detailed specification 
of SRVT procedures, messages and initiation 
of the procedure are for further study. 

• Long-term measurement collection deals 
with establishing sets of data (as defined in 
Recommendation Q.791) to be collected in a 
SP over a period of time. The procedures also 
enable the transfer of data when requested 
by a controlling function. This activity takes 
place periodically at all SPs in the signalling 
network, the data collected being transferred 
to an O & M centre either on demand or 
according to a set schedule. 

The functions contained are parameter 
initialisation and parameter modification such 
as to allow or inhibit measurement collection. 

The information elements in the procedure 
are command, controlling address and 
measurement. 
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O On-occurrence measurement reporting 
deals with the transfer and control of the 
measurements specified in Q.791 that are 
required to be reported to an O & M centre 
on occurrence. The record of an on-occurrence 
measurement is referred to as an indicator or 
event indicator. 

The functions contained are parameter, 
initialisation, parameter modification (that is, 
create a logging file, inhibit event logging, 
change event reporting threshold etc.), event 
indicator reporting and recovery of recent on- 
occurrence measurement history. 

The information elements required are con¬ 
trolling address, controlled address, effected 
address, command, file name, size, event type, 
threshold, time stamp and additional infor¬ 
mation as required. 

• Delay measurements deal with the meas¬ 
uring of delays across the signalling network 
on both a point-to-point and loop basis. The 
detailed specification of functions and infor¬ 
mation elements is for further study. 

# Clock initialisation provides a means for 
setting clocks in an SP for O & M and other 
purposes. This allows the signalling network 
to be synchronised to a unique time. The 
specification of functions and information 
elements required is for further study. 

$ Real-time control allows automatic or 
manual control in a controlled SP to be taken 
based on an input from the controlling SP. 
The controlling SP may initiate this procedure 
when it receives, for example, an input from 
an occurrence measurement reporting. The 
functions and information elements for this 
procedure are for further study. 

$ Operations provide a capability to per¬ 
form operations such as activation of links, 
within the signalling network. The detailed 
specification of functions and information 
elements required is for further study. 

Operations and Maintenance Procedures 
for Exchanges 

OMAP will eventually contain procedures to 
allow O & M control of exchanges supported 
by the CCITT No. 7 network. Procedures will 
also be specified within OMAP for O & M 
aspects that are common to both exchange 
and signalling network functions. 

Support of General Operations and 
Maintenance Procedures in a Network 

OMAP is seen as not only providing O & M 
support for the CCITT No. 7 network, but 
also, together with TC and SCCP, providing 
general data carrying capability for generic 
O & M activity in the main network. Studies 
are now being initiated on producing a TMN 
for digital networks and OMAP will provide 
the necessary protocol; this will enable the 
CCITT No. 7 network to provide the required 



SP: Signalling point STP: Signalling transfer point 

Note 1: Operations and maintenance part (OMAP) is located at all SPs where 
messages are terminated. 

MTP routing verification test (RVT) message contains: 
identifying code, 

originating and test destination point codes, 

threshold N giving maximum number of STPs allowed, 

result expected for ail cases, or result expected on failure identification 

only. 

MTP routing verification acknowledgement (RVA) message contains: 
identifying code, 

list of STPs crossed by acknowledged RVT, 

RVR sent/not sent indicator, 
test result: success, 

partial success, 
detected loop, 

detected excessive route length, 
unknown destination point code, 

RVT not sent (inaccessiable destination), 

RVA received timer expired, 
unknown originating point code, 
test failed due to local SP. 

MTP routing verification result (RVR) message contains: 
identifying code, 
test destination point code, 
test result, 

information field: point codes of STPs crossed on success, 

point codes of STPs crossed when excessive route 
length detected, 

no information when test destination point is unknown, 

RVA not received or failure at SP, 

if RVT not sent point code of inaccessible SP, 

SP unknown—point code of RVA SP. 


data communications network. To achieve 
this, OMAP requires the following capabili¬ 
ties: 

• Addressing allows the user of OMAP 
(for example, SMAP) to address applications 
in nodes in the signalling network or to address 
applications in nodes in any interconnected 
network. 

• Distribution enables the transported 
information to be delivered to the appropriate 
O & M application within the destination 
node. 


Figure 8 

Examples of MRVT 
generated message 
flows across the 
CCITT No. 7 network 
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• Connection-oriented communication 
enables a connection, whether physical or 
logical, to be established between two signal¬ 
ling points. This is required when the amount 
of O & M information to be transported is 
such that the overheads required for a connec¬ 
tionless transaction would make data carrying 
inefficient. An example of its use would be for 
transfer of statistical data that is not real¬ 
time sensitive from an exchange to the oper¬ 
ations and maintenance centre (OMC). 

9 Connectionless communication allows 
the transfer of O & M information between 
two SPs without establishing a connection. 
An example of the use of this capability is the 
transfer of event indicators as used in on- 
occurrence measurement reporting. This pro¬ 
cedure avoids delay in establishing a connec¬ 
tion for this real-time sensitive activity. 

• File transfer provides the means for com¬ 
munication between O & M applications 
which require file transfers. An example of its 
use is the transport of files generated by long¬ 
term measurement collection. 

With the progress of studies in TMN and 
O & M, the capabilities required in OMAP 
and by OMAP may well increase. However, 
as can be seen from those capabilities required 
at present, TC provides the ideal underlying 
support, and OMAP is a highly appropriate 
user of TC. 

OMAP, as presently specified in CCITT 
Recommendation Q.795, is an application 
using TC that contains the MRVT. Other 
procedures may be required to provide O & M 
capability for the telecommunications net¬ 
work. 

At present, no decision has been taken by 
BT to introduce OMAP into the network. 

CONCLUSION 

This article has shown that modern digital 
signalling systems are necessary to keep pace 
with customer and administration demands 
for new services. By making use of modern 
stored-program control exchanges, TC not 
only meets the customers’ and administrators’ 
needs for a powerful and flexible signalling 
system, but, because use is made of the under¬ 
lying CCITT No. 7 signalling system which 
already exists in the BT network, TC has also 
proved to be a cost-effective solution. 

With the liberalisation of the communi¬ 
cations network and the demand for efficient 
and cost-effective international services by 
BT’s customers, it is necessary for BT to be 


actively involved in defining internationally 
recognised signalling protocol standards. 

The current specification of TCAP is suit¬ 
ably stable for administrations to offer some 
non-circuit-related services at an early stage. 
Much work still has to be done on the inter¬ 
mediate service part and on the service specific 
functions residing above TC. 
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CCru l Signalling System 6\S© a 7: Testing Strategy for 
the British Telecom Metwork 
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This article provides an overview of the background, philosophies and objectives for the testing of 
CCITT No. 7 (BT) common-channel signalling into the British Telecom UK network. The successful 
proving of the signalling system is a critical factor in BT's aim to rapidly modernise the public 
switched network. This article shows how BT has successfully introduced various implementations 
of CCITT No. 7 signalling into a live and complex network. 


INTRODUCTION 

Other articles in this issue of the Journal 
describe the various technical aspects of Bri¬ 
tish Telecom’s implementation of the com¬ 
mon-channel signalling system known as 
CCITT No. 7 (BT). This article describes the 
elements of the testing and proving of CCITT 
No. 7 (BT) signalling systems in order to 
give sufficient confidence for introduction and 
interconnection into the BT public switched 
network. 

In November 1987, BT achieved its pro¬ 
gramme of a fully digitally interconnected 
trunk network by bringing into service the 
fifty-third System X trunk exchange. BT also 
has in excess of 600 concentrator units 
parented over approximately 230 processor 
sites using CCITT No. 7 common-channel 
signalling. These processor sites (local exch¬ 
anges) are dual parented into the trunk net¬ 
work by using CCITT No. 7 signalling. BT is 
installing new local digital units/exchanges 
interconnected by CCITT No. 7 at the rate 
of two each working day, to give a fully 
integrated digital switching and signalling 
network by 1992. 

In addition, BT has introduced CCITT 
No. 7 (BT) signalling between an AXE 10 
international exchange and the trunk network, 
and is to bring into service, during early-1988, 
a digital international switching centre and 
operator services complex with an inter¬ 
national and national interface by using 
CCITT No. 7 (BT) signalling; a further inter¬ 
national switching centre interfacing the 
trunk network via CCITT No. 7 (BT) signal¬ 
ling is currently being installed and is planned 
to come into service during 1988. From late- 
1987, CCITT No. 7 will also increasingly be 
used from each international switching system 
to replace and augment the current inter¬ 
national network. BT already has an extensive 
international network based on CCITT No. 6 
signalling. 

t Network Systems Engineering (Switching and 
Signalling) Department, British Telecom UK Com¬ 
munications 


It is believed that BT has the largest and 
most complex CCITT No. 7 common-channel 
signalling network in the world; it comprises 
an estimated 5500 CCITT No. 7 signalling 
links. The early experiences of the introduc¬ 
tion and interconnection of different 
implementations of CCITT No. 7 signalling, 
and the development of appropriate testing 
strategies and test equipment, has provided 
BT with a high degree of confidence in real¬ 
ising the interconnection of various implemen¬ 
tations of CCITT No. 7 into an active net¬ 
work. 

BACKGROUND 

CCITT No. 7 is a complex signalling system; 
its specification is provided to manufacturers 
for development and implementation, but any 
specification regardless of its completeness 
will be subject to slight differences of 
interpretation between implementors. 

The problem is compounded by the fact 
that there will be a large number of different 
CCITT No. 7 realisations (see Table 1) 

TABLE 1 

Interworking Situations 


ORGANISATION 

SYSTEM 

System X 

AXE 10 

5ESS 

Motorola 

EMX 

British Telecom UK 
Communications 

Yes 

Yes 

Yes 


British Telecom Inter¬ 
national 


Yes 

Yes 


Telecom Securicor 
Cellular Radio 




Yes 

Racal Vodaphone 


Yes 



Telecom Eireann 


Yes 



Hull 

Yes 




Manx 


Yes 



Mercury 

Yes 




Channel Isles 

Yes 
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resulting from the introduction of various 
switching systems within the BT network, and 
resulting from interconnection to networks of 
other licensed operators and administrations. 
The CCITT No. 7 signalling system is 
evolving and will continue to do so to support 
new customer and network features by means 
of new user parts (for example, the ISDN 
user part (ISUP)) or enhancements to existing 
user parts. At any one time, therefore, there 
are within each system (that is, System X, 
AXE 10, etc.) various versions of implemen¬ 
tation at various stages of evolution and at 
different levels of development. 

Switch manufacturers design their switch- 
recovery actions around their own system 
architecture, and the signalling system 
recovery actions are normally designed to 
interwork to the same implementation. How¬ 
ever, both of these actions are independent of 
the signalling network and the interaction 
between the two must be taken into account 
in order to identify any possible incompati¬ 
bilities. 

For the above reasons, it was necessary for 
BT to define a coherent testing strategy that 
ensured that systems being introduced or 
enhanced: 

® met BT’s interface specification on CCITT 
No. 7, 

O successfully interworked with other sys¬ 
tems in the network, 

• did not jeopardise the security and stability 
of the network, and 

$ were subject to the same criteria of vali¬ 
dation. 

TESTING PHILOSOPHY 

The testing philosophy agreed within BT con¬ 
sists of three main elements: 

# test specifications, 

Figure 1 ® test strategy, and 

Typical network ® test tools, 

interworking test 

configuration 



Test Specification 

Three types of testing were identified and 
these are described in British Telecom Net¬ 
work Requirement (BTNR) 954: 

(a) interface validation testing, 

( b ) interworking testing, and 

(c) commissioning testing. 

It is important to note that the responsibility 
for specification conformance and validation 
of new systems of CCITT No. 7 lies entirely 
with the manufacturer. Manufacturers of BT- 
supplied systems undertake a comprehensive 
programme of testing before the system is 
handed over to BT; this testing makes use of 
BT-produced specifications and test tools. 

Interface Validation Testing 

The purpose of interface validation testing is 
to prove that a particular realisation of the 
interface conforms to protocols as defined in 
the specification and can satisfactorily work 
to an already proven implementation. The 
tests are divided into protocol, provocative 
and functional tests. Protocol and provocative 
tests are performed by using test tools 
developed by BT (described below) which 
can generate and receive messages from the 
system under test. Protocol tests are concerned 
with the validation of the sequence and con¬ 
tents of messages passing over the CCITT 
No. 7 interface under test, and to prove that 
these are compliant with the CCITT No. 7 
interface specifications. The purpose of a pro¬ 
vocative test is to test the function of the 
system under test when invalid messages or 
invalid values are sent to it, to check that it 
can handle these sequences in a controlled 
manner without affecting service. 

Functional tests are those which use two 
exchanges or captive exchange models which 
are identical, in terms of their software and 
hardware, to the exchanges either being used 
or planned for use in the network. The objec¬ 
tive of the tests is to prove that, in as near a 
live environment as is possible, the realisation 
of signalling system CCITT No. 7 used at 
each exchange is fully compatible with the 
version used at the other exchange. See 
Figure 1. 

In effect, this testing provides BT with a 
high degree of confidence that a product is 
likely to be acceptable to interface to the 
network. 

Interworking Tests 

The purpose of interworking testing is to 
ensure that a new exchange system incorpo¬ 
rating CCITT No. 7 signalling interworks 
with the rest of the network over its CCITT 
No. 7 links. These tests are made into the BT 
network from the particular exchange type 
requiring connection by using test traffic to 
exercise the necessary functions of the CCITT 
No. 7 interface. There might be tests which 
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could endanger the service provided by an 
operational exchange carrying live traffic and 
therefore these interworking tests are per¬ 
formed on an exchange not yet carrying live 
traffic or on a non-operational exchange (cap¬ 
tive model). 

The objective is to pass at least one test call 
from each exchange type, each signalling type 
and customer type connected in the existing 
network to the system under test via the 
CCITT No. 7 signalling system. Testing nor¬ 
mally takes place at the first network exch¬ 
ange at which the system under test first 
connects to the BT network with CCITT 
No. 7. Some of the tests are repeated at sub¬ 
sequent connections to the BT network. 

There are also tests of an operations and 
maintenance, provocative, and overload 
nature designed to prove that actions on an 
exchange at one end of a CCITT No. 7 link 
do not have undesirable effects upon a system 
at the other end of the link. These tests are 
performed on operational exchanges not car¬ 
rying live traffic or on a non-operational exch¬ 
ange or model. 

Commissioning Tests 

The purpose of commissioning tests is to allow 
CCITT No. 7 signalling routes to be added to 
an exchange (which may or may not be in- 
service) or to allow changes to be made to 
existing signalling routes and the network. 
The tests prove that the correct data has been 
loaded in the exchanges concerned so that 
calls can be correctly established, and simple 
tests are performed to prove that the basic 
security functions within the signalling system 
operate successfully. 

TEST STRATEGY 

BT has produced a single ‘generic’ test speci¬ 
fication for CCITT No. 7 (BT) signalling 
(BTNR 954) which covers the complete set 
of tests for interface validation, interworking 
and commissioning testing; bilateral dis¬ 
cussions are required between respective inter¬ 
connect parties to agree a subset of tests from 
the generic set appropriate for the specific 
implementation and interconnect situation. 
These would exercise those protocols appro¬ 
priate to the interconnect to give an administr¬ 
ation a high degree of confidence that the 
system would perform satisfactorily when car¬ 
rying live signalling traffic. 

For new implementations, comprehensive 
testing is performed to prove the total 
implementation of CCITT No. 7 signalling 
protocols; for enhancements, an agreed level 
of retest and regression testing is performed 
on captive units prior to loading onto a 
working live system. This is to give the level 
of confidence necessary before loading the 
new software or installing new or modified 
hardware for trialling the build on a working 
unit prior to interconnection to the network. 


The first connection of a new system to 
the network requires a comprehensive set of 
interface validation, interworking, and com¬ 
missioning tests to be conducted. For sub¬ 
sequent connections of that system to the 
network only a limited subset of interworking 
tests and commissioning tests need be done. 

Also, if a new system has been introduced to 
the network by proving to one type of existing 
exchange in the network (say System X), then 
its connection to a second existing exchange 
in the network (say AXE 10 local) does not 
require all the tests to be repeated. Only a 
limited set of interworking and commissioning 
tests need be done. Any other course of action 
would result in every exchange type being 
tested to every other exchange type, and this 
would lead to a never ending programme of 
testing as new systems and variants of existing 
systems are introduced into the network. 

TEST TOOLS 

Testing all protocols of a new signalling 
system specification, including provocative 
actions resulting from out-of-sequence or cor¬ 
rupted sequences, is a very extensive activity 
and is specially difficult without the proper 
test equipment. Testing a complete system as 
complex as CCITT No. 7 is thought to be 
impracticable without complex flexible pro¬ 
tocol testing equipment. Implementations of 
CCITT No. 7 do not have the capability to 
generate or receive corrupt, out-of-sequence 
or provocative messages/protocols to test 
reactions on receipt or generation of such 
messages or protocols. Implementations can 
contain dormant software faults or protocol 
incompatibilities that only become apparent 
on interconnection to other implementations. 

Therefore, specialised testers were considered 
necessary to perform this level of flexibility of 
testing. 

BT Tester—Martinet 

BT has developed a CCITT No. 7 tester called 
Martinet (Figure 2) which is capable of exerc¬ 
ising all Level 2, 3 and 4 protocols, and is Figure 2 

capable of generating messages in any Martinet 
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sequence to test how the product would per¬ 
form under mis-sequencing and fault con¬ 
ditions. The use of this tester has proved 
invaluable to BT in the testing of systems 
before interconnection or going live and has 
allowed interworking difficulties to be resolved 
before live interconnect is established. Mar¬ 
tinet is designed to enable a large amount of 
testing to be carried out in a short time. Tests 
of both normal and, possibly more impor¬ 
tantly, provocative signalling protocols can be 
performed. 

As indicated in earlier articles, the oper¬ 
ation of CCITT No. 7 can be expressed as 
sequences of messages between the systems 
in a network. Within each exchange system, 
CCITT No. 7 is divided into levels, each of 
which communicates with the corresponding 
levels of other exchange systems. Martinet is 
capable of stimulating a network of exchange 
systems and performing many possible mess¬ 
ages, both normal and abnormal, at all levels. 
It is therefore possible to test the protocols 
and facilities of the message transfer part, 
telephony and ISDN user parts, signalling 
connection control part and transaction capa¬ 
bilities. 

Each test or message sequence to be per¬ 
formed is written as a test script. This is a 
series of commands to send messages, check 
the receipt of messages, start and stop timers 
etc. as needed to test the required message 
flow. The values of the fields within the mess¬ 
ages are easily alterable to values appropriate 
for the test concerned. See Figure 3. 

In addition to performing message 
sequences, Martinet is capable of generating 
high signalling traffic loads, of several hun¬ 
dred messages per second on each link to be 
handled by the system under test. 

The results of a test run—messages sent 
and received, incorrect field values, expired 


time-outs, messages lost or mis-sequenced 
etc.—can be output to screen, disc or printer. 
The amount of data which is displayed is 
selectable; this enables the output of infor¬ 
mation to be tailored to meet specific require¬ 
ments. 

FUTURE TESTING REQUIREMENTS 

Testing New Implementations in a Fully 
Interconnected Network 

Currently, enhancements or new implemen¬ 
tations are introduced into the network with 
a limited number of interconnected signalling 
and traffic routes to the rest of the network. 
This was allowed by the use of exchanges that 
were either installed, but not carrying live 
traffic or had low traffic levels. With the 
current plans for oft-loading analogue traffic, 
the entire trunk network traffic should be 
carried digitally by 1989, and all of the digital 
local exchanges will be in place by 1992. This 
implies that a lightly loaded node with limited 
interconnections will not be available to be 
used as a trial system for the introduction 
of more enhanced versions of CCITT No. 7 
signalling. The current strategy will therefore 
need to be modified to cater for this situation 
in order to give adequate confidence that a 
new implementation of CCITT No. 7 signal¬ 
ling does not make the total network unstable 
on its introduction. 

A proposal currently being examined by 
Network Systems Engineering (Switching 
and Signalling) Department is to use available 
captive exchanges. These will be used initially 
for the interface validation and interworking 
tests specified in BTNR 954. Systems which 
have gone through BTNR 954 tests will then 
be subject to a period of network trial by 
being loaded on these captive models, which 
will have a limited number of connections to 


Figure 3 

Example BTNR954 test 
script and runfile 


EXAMPLE BTNR 954 TEST SCRIPT 


EXAMPLE RUNFILE FOR TEST SCRIPT 


BASIC CALL SET UP 

Test Harness 
Message Circuit 

1AM A 

A 

FAM A 

A 
A 

REL A 



SEND: 

IAM 

REF 

PCI 

OG 

CCTA 

System Under Test 

WAIT: 

SAD 

REF 

PCI 

OG 

CCTA. MAXTIME tmr TO 9 MIN. 

Message 


EXTRATIME tmrmed 




SEND: 

FAM 

REF 

PCI 

OG 

CCTA 

SAD 

WAIT: 

ACM 

REF 

PCI 

OG 

CCTA. MAXTIME tmr TO 9 MIN. 



EXTRATIME tmrmed 



ACM 

REPORT: 

'ANSWER THE CALL' 



ANS 

WAIT: 

ANS 

REF 

PCI 

OG 

CCTA. MAXTIME tmr TO 9 MIN, 


EXTRATIME tmrmed 



CCTF 

SEND: 

REL 

REF 

PCI 

OG 

CCTA 


WAIT: 

CCTF 

REF 

PCI 

OG 

CCTA. MAXTIME tmr TO 12 MIN. 


EXTRATIME tmrmed 


ENDTEST: 


IAM: Initial address message 
SAD: Send all digits 
FAM: Final address message 
ACM: Address complete message 


ANS: Answer 
REL: Release 
CCTF: Circuit free 


In the runfile, the information following the message refers to the particular circuit; that is, PCI: point code 1; OG: outgoing; CCTA: circuit A. 
MAXTIME and EXTRATIME refer to software timers specified in the runfile. ‘tmr’ refers to timer, and ‘tmrmed’ to timer medium. 


British Telecommunications Engineering , Vol. 7, April 1988 


69 










the digital public switched network. This will 
ensure that any problems in the new 
implementation which could lead to instability 
of the network are quickly identified and will 
have only a limited adverse effect on the 
network. This will also ensure that disruption 
to customer service is minimised or avoided. 

Testing of New User Parts 

The current test specification (BTNR 954) 
contains tests only for the national user part 
and the message transfer part. With the future 
introduction of transaction capability and the 
signalling connection control part, as 
described in other articles in this Journal , new 
test specifications and enhancements to test 
tools will be introduced. 


SUMMARY 

CCITT No. 7 is a complex signalling system 
which requires extensive validation and 
testing before it can be confidently introduced 
into the public switched network. BT has 
adopted a philosophy of testing CCITT No. 7 
which is consistent with the requirement to 
have a number of various switch types in the 
network and the need to subject each system 
to a uniform criteria of validation. The test 
philosophy has resulted in the formulation of 
a test strategy, the production of test specifi¬ 
cations, and the development of specialised 
test tools. This has allowed the successful 
introduction of the world’s largest and most 
complex CCITT No. 7 signalling network. 
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Glossary of Abbreviations 


ACM 

Address complete message 

OSS 

Operator services subsystem 

ADPCM 

Adaptive differential pulse-code modulation 

PCR 

Point code routing 

AK 

Data acknowledgement 

PSTN 

Public switched telephone network 

BCD 

Binary coded decimal 

PTO 

Public telecommunications operator 

BES 

Business exchange services 

RI 

Routing indicator 

BT 

British Telecom 

RLC 

Release complete 

BTNR 

British Telecom Network Requirement 

RSC 

Reset confirm 

CC 

Connection confirm 

RSLD 

Released 

CCITT 

International Telegraph and Telephone 

RSR 

Reset request 


Consultative Committee 

RST 

Route-set test 

CDA 

Called address 

RVA 

Routing verification acknowledgement 

CGA 

Calling address 

RVR 

Routing verification result 

CIC 

Circuit identification code 

RVT 

Routing verification test 

CLI 

Calling line identity 

SAM 

Subsequent address message 

CPI 

Call path indicator 

SCCP 

Signalling connection control part 

CPM 

Call progress message 

SCMG 

SCCP management 

CR 

Connection request 

SHP 

Service handling protocol 

CREF 

Connection refused 

SIB 

Status indication busy 

CUG 

Closed user group 

SIE 

Status indication emergency 

CVT 

Circuit validation test 

SIF 

Signalling information field 

DAN 

Database access node 

SIM 

Service information message 

DASS 

Digital access signalling system 

SIN 

Status indication normal 

DDSN 

Digital derived services network 

SIO 

Service information octet (Level 3 function) 

DMSU 

Digital main switching unit 

SIO 

Status indication out of alignment (Level 2 

DPC 

Destination point code 


function) 

DTI 

Data form 1 

SIOS 

Status indication out of service 

DT2 

Data form 2 

SIPO 

Status indication processor outage 

EA 

Expedited data acknowledgement 

SLC 

Signalling link code 

ED 

Expedited data 

SLM 

Signalling link management 

ERR 

Protocol data unit error 

SLS 

Signalling link selection 

FIC 

Facility indicator code 

SLT 

Signalling link test 

FISU 

Fill in signal unit 

SMAP 

System management process 

GT 

Global title 

SMH 

Signalling message handling 

GTR 

Global title routing 

SNM 

Signalling network management 

HLR 

Home location register 

SOG 

Subsystem out-of-service grant 

IA5 

International Alphabet No. 5 

SOR 

Subsystem out-of-service request 

IAM 

Initial address message 

SP 

Signalling point 

IFAM 

Initial and final address message 

SPC 

Stored-program control 

ISDN 

Integrated services digital network 

SRM 

Signalling route management 

ISP 

Intermediate service point 

SRVT 

SCCP routing verification test 

ISRM 

Initial service request message 

SSA 

Subsystem allowed 

ISUP 

ISDN user part 

SSN 

Subsystem number 

IT 

Inactivity test 

SSP 

Subsystem prohibited 

LSSU 

Link status signal unit 

SST 

Subsystem status test 

LSU 

Local switching unit 

STM 

Signalling traffic management 

MAP 

Mobile application part 

STP 

Signal transfer point 

MCI 

Malicious call identification 

TC 

Transaction capabilities 

MRVT 

MTP routing verification test 

TCAP 

Transaction capabilities application part 

MS 

Mobile station 

TFA 

Transfer allowed 

MSC 

Mobile switching station 

TFC 

Transfer controlled 

MSU 

Message signal unit 

TFP 

Transfer prohibited 

MTP 

Message transfer part 

TFR 

Transfer restricted 

NI 

Network indicator 

TMN 

Telecommunications management network 

NUP 

National user part 

TPUP 

Test process user part 

O&M 

Operations and maintenance 

TUP 

Telephony user part 

OMAP 

Operations and maintenance application part 

UDT 

Unit data 

OMC 

Operations and maintenance centre 

UDTS 

Unit data service 

OPC 

Originating point code 

VLR 

Visitor location register 

OSI 

Open systems interconnection 

VPN 

Virtual private network 
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THE INSTITUTION OF 
BRITISH TELECOMMUNICATIONS 
ENGINEERS 

(Founded as the Institution of Post Office Electrical Engineers in 1906) 


General Secretary: Mr. J. H. Inchley, NPW2.1.6, 4th Floor, 84—89 Wood Street, London EC2V 7HL; Telephone: 01-250 9816. 
(Membership and other enquires should be directed to the appropriate Local-Centre Secretary as listed on p. 211 of the October 1987 issue.) 


SUBSCRIPTIONS TO THE INSTITUTION AND TO 
THE FEDERATION OF TELECOMMUNICATIONS 
ENGINEERS OF THE EUROPEAN COMMUNITY 
(FITCE) 

The Council of the Institution has determined that, with 
effect from 1 May 1988, the annual subscription for Mem¬ 
bership of the Institution will be increased from £4-92 to 
£6-60, or by 14p per month. 

The annual subscription for Membership of FITCE 
remains at £5-00. 

MEMBERSHIP BROCHURE 

The Institution has produced a brochure outlining the ben¬ 
efits of Membership of the Institution. If you are not cur¬ 
rently a Member and wish to know more about the services 
and facilities, or know of a colleague who might be interested, 
please contact your Local-Centre Secretary for a copy. 


fostering and developing interest in FITCE with the IBTE. 
Dr. P. Bailes, Deputy Director Networks, was formally 
appointed to the post. The following nominations were also 
endorsed: 

Honorary Treasurer: Mr. P. Allen, replacing Mr. R. New. 

Assistant Secretary, Finance: Mr. J. White, replacing Mr. 
J. E. Short. 

Assistant Secretary, FITCE: Mr. T. K. Ray, replacing 
Mr. P. A. P. Joseph (effective immediately). 

Secretary/Treasurer, BTE Journal : Mr. C. Fennell, 
replacing Mr. B. Farr. 

The posts will, with the exception of the Assistant Sec¬ 
retary, FITCE, become vacant at the end of the current 
Session with the resignation of the present postholders. 
Grateful thanks are due to the departing Officers, who have 
each made significant contribution to the successful and 
smooth running of the Institution. 


AMENDMENTS TO THE RULES OF THE 
INSTITUTION 

Institution Rules concerning the presenting of Local Awards 
in respect of lectures given by Members of the Local Centre, 
and the presenting of National Awards have been amended. 
The changes have been certified by the Chairman of Council 
as clarification of the existing Rules, and become effective 
forthwith. The changes are as follows: 

Rule 47 

‘Lectures of a sufficient standard given by a Member of 
a Local Centre shall be considered by that Centre for a 
Local Centre Award, which will consist of a cash prize of 
such a sum as is determined from time to time by Council, 
accompanied by an Institution Scroll. No Centre shall make 
more than one Local Award in a Session. 

Lectures reaching the required standard given by Mem¬ 
bers of a Centre other than the Local Centre shall be 
recommended to the National Awards Committee for con¬ 
sideration for a National Award, of which no more than two 
may be made in any one Session. In the case of a lecture 
unsupported by a paper, this shall consist of a Medal and 
an Institution Scroll. Where a lecture is supported by a 
written paper, the National Awards Committee may rec¬ 
ommend one major Institution Award per Session, which 
shall consist of a prize in a form other than cash to the value 
of not more than £500, accompanied by a Medal and 
Institution Scroll. 

Medals and Scrolls for the National Awards shall be 
presented at the Annual General Meeting of the Institution 
at the end of the succeeding Session.’ 

OFFICERS OF THE INSTITUTION 

At a recent Meeting of Council in Westward Centre, Council 
created a new post of Secretary, FITCE, charged with 


NEW ASSISTANT SECRETARY (FITCE) 

Future correspondence relevant to FITCE matters should 
be addressed to the new Assistant Secretary (FITCE): 
Tapash Ray, UKC/NPW4.1.6, 3rd Floor, Wing D, The 
Angel Centre, 403 St John’s Street, London EC IV 4PL; 
Telephone: 01-239 0810. 


RETIRED MEMBERS 

The following Members have retained their membership of 
the Institution under Rules 10(a) and 13 (a). 


G. I. Andrew 

G. F. Barnes 
P. Bastow 

P. L. Blanchard 

H. W. Bright 
K. R. Carter 

S. Cavies 

T. M. Coleman 

G. A. Craig 
J. Davidson 
W. F. Eyeington 


‘Barrymore’, White Farm Lane, 
West Hill, Ottery St. Mary, 
Devon EX 11 1XF 
3 Shelley Road, Kettering, 
Northants NN16 9LD 

17 Grange Close, Bardsey, 

Leeds LSI7 9AX 

3 Marshfield Way, Fairfield 
Park, Bath, Avon BA1 6HA 

18 Hillary Road, Rugby, 
Warwickshire CV22 6EU 
80 Sunnybank Road, Potters 
Bar, Hertfordshire EN6 2NF 
9 Coniston Road, Fulwood, 
Preston, Lancashire PR2 4AX 
‘Gormay’, Kings Mill Lane, 
Painswick, Stroud, 

Gloustershire GL6 6SA 

7 Berryden Road, Aberdeen, 
Scotland AB2 3SB 
75 Fonthill Road, Aberdeen, 
Scotland AB1 2UP 
‘Antofts’, East Lane, Shipton by 
Benningbrough, York Y016 
1AH 
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E. D. Forbes 

‘Spindles’, 5 The Quarries, 
Almondsbury, Bristol BS12 

4HL 

K. G. Fretten, 

165 Cotton Hill Lane, St. 
Albans, Hertfordshire AL1 

2EX 

P. Garrick 

27 Macers Lane, Wormley, 
Broxbourne, Hertfordshire 

EN10 6EQ 

D. Gaukrodger 

29 Poolfield, Solihull, West 
Midlands B91 1SH 

R. A. Green 

31 Linley Wood Road, 

Aldridge, Walsall, West 
Midlands WS9 OJZ 

G. P. Harris 

11 Pine Close, North Baddesley, 
Southampton S05 9HN 
‘Pippins’, 3 Agar Meadows, 
Carnon Downs, Truro, Cornwall 
TR3 6HS 

G. W. Harris 

J. D. Harrap 

26 Top Road, Barnby Dun, 
Doncaster, South Yorkshire 

DN3 IDA 

J. C. Henderson 

8 Hawthorn Place, Woodbridge, 
Suffolk IP12 4JZ 

H. Hodgson 

103 Lidgett Lane, Leeds, West 
Yorkshire LS8 1QR 

G. Hulme 

79 Kingsley Road, Talke Pits, 
Stoke on Trent, Staffordshire 
ST71RB 

W. Kirkby 

178 Forest Gate, Harrogate, 
North Yorkshire HG2 7EE 

G. Mitchell 

Beech Acres, Chinnor Hill, 
Chinnor, Oxon 0X9 4BQ 


F. D. Noble 

1 Highway, Edgcumbe Park, 
Crowthorne, Berkshire RG11 
6HE 

D. J. Norman 

19 Wanderdown Road, 
Ovingdean, Brighton, East 
Sussex BN2 7BT 

J. Pemberton 

124 Biddulph Road, Congleton, 
Cheshire CW12 3LY 

B. Pilcher 

49 Dogwood Close, Gravesend, 
Kent DA 11 8PJ 

G. L. Roberts 

300 Saughall Road, Blacon, 
Chester CHI 5HQ 

R. Schofield 

14 McConnell Road, Moston, 
Manchester M10 9DP 

P. C. Smart 

5 Beaconhill Drive, Worcester 
WR2 6DL 

J. D. Smith 

5 Hillside Way, Godaiming, 
Surrey GU7 2HN 

P. R. Smith 

10 Cavie Road, Braunton, 

Devon EX33 1DX 

J. Surtees 

9 Tanmeads, Nettlesworth, 
Chester Le Street, County 
Durham DH2 3PX 

G. E. Taylor 

20 Paddock Mead, Harlow, 
Essex 

J. F. T. White 

6 Hawthorn Road, Godaiming, 
Surrey GU7 2NE 

H. Yearl 

191 Tamworth Road, 
Kettlebrook, Tamworth, 
Staffordshire B77 1BT 

J. H. Inchley 


Secretary 


The Federation of Telecommunications 
Engineers of the European Community 



The Federation des Ingenieurs des Telecommuncations de 
la Communaute Europeenne (FITCE) was established by 
European telecommunications engineers to improve the 
standing of engineers throughout the EEC, to activate 
friendships across the frontiers to the benefit of the public 
telecommunications service and to suggest means of 
resolving mutual technical problems in a national and uni¬ 
form way. 

FITCE was formally constituted as a chartered institution 
in October 1961 with six founder member countries. Its 
Rules are based on the concept that members admitted to 
FITCE from different countries should go through their 
national association of telecommunications engineers and 
should, as far as possible, have a similar level of responsibility 
and common work interests. Full membership was offered 
to those holding a responsible position in a public telecom¬ 
munications service who had been educated to university 
level. 

There are now 12 member countries in FITCE including 
the UK, which is represented by the IBTE: 


West Germany 

Denmark 

Belgium 

Spain 

France 

Greece 

Italy 

Ireland 

Luxembourg 

Portugal 

Netherlands 

UK 

To realise its objectives, 

FITCE organises a technical 


Congress which is held in a different European city each 
year. Each Congress is devoted to a technical theme with 


the presentation of papers followed by discussion. Multi¬ 
lingual translation facilities enable all those present to par¬ 
ticipate. Some time is also devoted to technical visits and 
cultural events and a programme of visits is also organised 
for the partners of Congress members. 

The 1987 Congress, the twenty-sixth, was held in Athens, 
Greece. As usual, it was a prestigious occasion attended by 
nearly 600 members and accompanying persons. The theme 
chosen for the Congress was ‘European Telecommunications 
Objectives’. Thirty papers were presented including papers 
from Tony Valdar (Private Circuit Services, British Telecom 
UK Communications), and Peter Jones (Central Territory, 
British Telecom UK Communications). At the end of each 
Congress, an award is given to the ‘best paper’: Peter Jones 
was the worthy recipient on this occasion. 

The 1988 Congress is to be held in Cork, Ireland, and 
IBTE/FITCE members should have already received 
advanced notification. Further information on the Congress 
will be given in the FITCE Revue magazine, but members 
wishing to attend may contact Jon Inchley, IBTE Secretary, 
for further advice. 

Members may also wish to note that FITCE is planning 
to hold its 1990 Congress in the UK. Planning has already 
begun in BT to ensure that the event compares well with 
the efforts of our European colleagues. More detailed infor¬ 
mation will be announced in due course. 

A. B. Wherry 
Membre de Comite de Direction, and 
Vice-Chairman, IBTE Council 
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Institution of 

British Telecommunications 
Engineers 

Associate Section National Committee 


NATIONAL PROJECTS COMPETITION 

The Associate Section’s National Projects Competition was 
started in 1974 with a poster design competition. This was 
followed in 1975 with one to design a new membership form. 
In 1976, the first project competition of a more technical 
nature was announced, the object being to design and build 
an electronic quiz timer and scorer. Since then, the compe¬ 
tition has been held every year, some with a fixed subject, 
others being left open. 

With the advent of home computers in the early-1980s, 
computer software entries started to appear. This made the 
judging much more complex; it was difficult enough trying 
to judge entries of electrical projects against mechanical 
ones. Consequently, for the 1983 competition, the judging 
panel included someone from the Data Processing Executive. 
In 1984, London Centre offered an additional trophy to the 


National Committee. This was accepted, and the projects 
competition was divided into two: the E. W. Fudge Trophy 
for hardware projects and the London Trophy for software 
projects. 

The competitions are open to all members of the Associate 
Section and, except when there is a ‘theme’, any project can 
be entered. As examples of the range of entries received, 
previous winners have included a TXE4 simulator, packet¬ 
switching floor alarm, hot-metal castings, quiz timer/scorer, 
Edgeley electronic queueing equipment, auto-dialler, mem¬ 
bership program, to mention but a few. Entry to the compe¬ 
titions does not exclude members from including the project 
in any BT-sponsored competition. 

There follows a brief description of last year’s entry from 
Edinburgh Centre, which, incidentally, won both the London 
and Fudge Trophies, entitled Digitally Interfaced Call¬ 
sending Equipment (DICE) by Steven Leask and David 
McLean. 


Digitally Interfaced Call-Sending Equipment 

S. LEASK, and D. McLEAN 


INTRODUCTION 

This article describes the concept and development of inter¬ 
face circuitry and associated software designed to control 
the operation of test-call sending equipment. 

Primarily, the interface, known as digitally interfaced 
call-sending equipment (DICE), allows a test-call sender to 
be linked to a computer in such a way that the call sending 
can be controlled from that computer. The project was 
begun as an aid for the Edinburgh Woodcroft report-and- 
investigation point to accelerate the localisation of faults 
based on results produced by the Edinburgh measurement 
and analysis centre (MAC). 

Previously, MAC failures were processed on a day-to-day 
basis, with local units receiving a daily print-out of the 
previous day’s results. In some situations, this meant that 
the figures could be up to 24 hours out of date, which left 
a significant gap in the procedure. It could be seen that it 
would be beneficial to maintenance staff if these results 
could be analysed and acted upon on a ‘real time’ basis. 

Further to this idea, it was suggested to look into the 
possibility of designing a system which could analyse the 
MAC failures as they occur and, if necessary, automatically 
initiate test-call sending on troublesome routes. In order to 
achieve this, it was necessary to construct a suitable item of 
equipment to interface the processing equipment to the test- 
call sender. The original development work was carried out 
on equipment already available in Woodcroft, namely a 


DMS Hi-Net computer system and a particular test-call 
sender (TRT284A). Further development since that time 
has shown that other processors (for example, Merlin/IBM 
PCs) and testers (for example, TRT285A) can also be used. 

SYSTEM OPERATION 

Figure 1 shows a block diagram of the current system in 
use. The DICE interface is shown connected to the parallel 



Figure 1—DICE system configuration 
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port of a Hi-Net workstation by means of a ribbon cable. 
The interface is then cabled to the test-call sender via a 
switching unit containing relays which duplicate the func¬ 
tions of various keys on the call sender. All manual input is 
done at the terminal, is menu driven and is fully user 
friendly. 

Data sent from the terminal is decoded by the interface 
(see Figure 2) to operate a relay to simulate a required key 
operation. The binary, hexadecimal and output values of the 
data being decoded are displayed on light-emitting diodes 
(LEDs) on the front of the interface unit. 

The interface had been designed as a separate ‘stand 
alone’ unit (see Figure 3) capable of being controlled by 
a wide range of software-based applications. It consists, 
essentially, of a series of 16 binary-controlled switches, the 
binary data being output by the DMS Hi-Net in parallel 
form as an 8 bit word. As only sixteen variables are required, 
only the four least significant bits (LSBs) are decoded, the 
remainder being either ignored or used to drive another 
interface unit. For example, for the word 1011 0101, the 
LSBs 0101 are decoded by the interface, and 1011 is ignored. 

From this, it can be seen that the values 0 to F (hex) can 
be obtained from the 16 permutations of binary values 0000 
to 1111. Further expansion could utilise the four unused bits 
to select, for example, one of up to 16 different call senders 
if a multiple testing system was required; that is, if more 
than one test-call sender was required to be controlled via 
a single interface at any one time. 

The 4 bit characters used in the prototype are detailed in 
Table 1. 



Figure 2—Block diagram of interface circuitry 



Figure 3—DICE interface units (foreground, right) shown with 
Tester 284A (back, right), VDU and keyboard 


TABLE 1 

DICE Control Characters 


Character 

Binary 0-7 

Oct. 

Dec. 

Hex. 

DICE operation 

0 

00110000 

060 

048 

30 

Digit 0 (zero) 

1 

00110001 

061 

049 

31 

Digit 1 (ONE) 

2 

00110010 

062 

050 

32 

Digit 2 (two) 

3 

00110011 

063 

051 

33 

Digit 3 (three) 

4 

00110100 

064 

052 

34 

Digit 4 (four) 

5 

00110101 

065 

053 

35 

Digit 5 (five) 

6 

00110110 

066 

054 

36 

Digit 6 (six) 

7 

00110111 

067 

055 

37 

Digit 7 (seven) 

8 

00111000 

070 

056 

38 

Digit 8 (eight) 

9 

00111001 

071 

057 

39 

Digit 9 (nine) 

J 

01001010 

112 

074 

4A 

Null value 

K 

01001011 

113 

075 

4B 

Dash (-) 

L 

01001100 

114 

076 

4C 

reset key 

M 

01001101 

115 

077 

4D 

ROUTE STORE key 

N 

01001110 

116 

078 

4E 

STEP ROUTE key 

O 

01001111 

117 

079 

4F 

start key 


The above character set was chosen for no other reason 
than to give a series of LSBs in the range 0-F (hex). 


SOFTWARE 

The software used to drive the DICE interface is written 
entirely in Microsoft BASIC 80, although it has been com¬ 
piled and linked into object code. The program resides on a 
Hi-Net system running the HiDos 6.1C multi-user operating 
system. The main functions of the software are: 

(a) to read numbers and parameters from a data file, 

(b) to store the relevant test numbers in the Tester 284A, 
and 

(c) to create a file of currently stored numbers. 

These functions are described below: 

(a) The Edinburgh MAC uses a GEC 2050 mini-com¬ 
puter to measure the performance of telephone exchanges 
within the District. The teletype output from this computer 
is fed into the Hi-Net system and processed every morning 
at approximately 07.30 hours. This produces an ASCII file 
containing call failures detected over the previous 24 hours. 
The file is accessed by DICE software which extracts the 
telephone number and information concerning the type of 
call failure. In the event of the data file containing insufficient 
information, the backup file is read; this contains test num¬ 
bers of ‘known troublesome routes’ through the exchange. 

(b) The digits are output on the Centronics parallel port 
along with various control codes for reset, start sending, 
route store etc. Because of the speed of operation of the 
DICE interface, the software introduces a delay between 
each output code. 

(c) The program produces an output file containing infor¬ 
mation about when the Tester 284A was last programmed 
and which 16 numbers are stored. 


FUTURE DEVELOPMENT 

Since the original project, the DICE concept has been 
applied to system data-build testing. A Tester TRT285A 
has been modified and a solid-state digital interface installed. 
This allows bi-directional transfer of data between the tester 
and a Merlin personal computer. It can be used to test the 
integrity of system data after bulk reloads. The complete 
system runs unsupervised, checking every national number 
group code for plant defects, plant congestion and correct 
tariff application. This job was previously performed manu¬ 
ally and took several days to complete. 
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Motes and Comments 


INCREASE IN SUBSCRIPTION RATES 

The price of the Journal to British Telecom and British Post 
Office staff will be increased to 90p per copy from the July 
1988 issue. 

BT NEWS MISCELLANY 

BT is supplying in Kenya a network of 113 digital electronic 
UXD5 telephone exchanges to serve rural communities. The 
exchanges and associated transmission equipment are being 
supplied at a cost of more than £30M under a contract 
between the Kenyan Telecommunications Authority and the 
London-based firm Communications Supplies Ltd. (CSL). 
As part of the project, BT will supervise the installation 
of the equipment and train Kenyan telecommunications 
engineers to operate and maintain it. 

A contract valued at £1-3M has been awarded to British 
Telconsult, BT’s overseas consultancy service, to develop 
and improve telecommunications in Sierra Leone, West 
Africa. The contract, funded by the European Economic 
Community, was won against strong competition from 
German, French and Italian consultancies. 

Under the project, which is being carried out for the 
Sierra Leone National Telecommunications Company, Bri¬ 
tish Telconsult is responsible for the overall management 
of some 20 separate equipment contracts, including the 
provision of a new digital exchange for the capital of Free¬ 
town and digital junctions for the greater Freetown area. 

Other major tasks cover the rehabilitation of Sierra 
Leone’s national trunk system, and the introduction of solar 
power at remote radio sites. A wide range of telecommuni¬ 
cations, power and environmental control plant will also be 
refurbished. 

IN January, BT’s Value-Added Services Division announced 
a major restructuring of its data services activities in an 
enlarged Dialcom Group. This will have four marketing 
arms, serving the US, the UK, Europe and other countries 
world-wide. Mr. John Morris, president of the US-based 
Dialcom, Inc., has been appointed chairman of the new 
international group, which, as a combined unit, will employ 
more than 900 people with initial annual revenues of $100M. 

The new Dialcom Group, due to be fully operational in 
April 1988, will combine Dialcom Inc; Telecom Gold, the 
UK’s prime public messaging service; BT’s value-added 
business services, which include Prestel; and the computer 
network services division which provides technical support 
for the UK operation. 

BT has placed further orders on Thorn Ericsson for AXE 10 
digital exchanges worth in excess of £20M and representing 
a total of 226 000 lines for its local exchange replacement 
programme. 

BT is to establish a £5M centre of excellence in advanced 
technology in Scotland after its decision to site its latest 
Systems and Software Centre in Glasgow. The new cen¬ 
tre—the fifth to be established by Research and Technology 
Executive—will employ graduates from Scottish universities 
and polytechnics to meet BT’s continually expanding need 
for expertise in developing high-technology systems. 

These centres undertake the design and development of 
computer-based systems and their associated software for 
other parts of BT. About 15 staff will be employed when 
the Glasgow centre starts work in April this year. This is 
expected to grow to 60 by 1990 and eventually to more than 
100 . 


bt has awarded contracts worth over £12M to Landis & Gyr 
Communications Ltd—part of the Landis & Gyr group—for 
the supply of Payphones 100 and 200 Mark II. The Payphone 
100 is a compact table-top coin-operated payphone that can 
be used by owner or renter as a normal telephone. The 
Payphone 200 Mark II is a wall-mounted version that 
provides all of the features of the Payphone 100, but with 
a larger cash container appropriate for the higher revenue 
environment. 

contracts worth approximately £5M have been won by BT 
to install data cable networks in 1220 branches of Lloyds 
Bank. The networks are being supplied as part of the 
bank’s £570M information technology project designed to 
streamline office systems in the bank’s UK branches. As 
part of the project, Lloyds Bank is to install approximately 
28 000 terminals and controllers. In turn, these will link the 
terminals to the bank’s new nationwide integrated voice and 
data network being set up under the project, to give access 
to more than 6000 computer devices. 

The cabling is planned to act as a token-ring local area 
network capable of operating at rates up to 16 Mbit/s. BT 
is also installing a large patch frame in each branch. This 
will be the hub of the cabling network in the branch, to give 
full flexibility in the interconnection of terminals and other 
equipment with controllers. Cabling has already been 
installed in 320 branches under an earlier contract. BT has 
been contracted to cable a further 900 branches. Work is 
expected to be finished by the end of September; on com¬ 
pletion, BT will have cabled about half of Lloyds Bank 
branch sites in the UK. 

BT has announced a joint venture with Systems Designers 
pic to market secure administrative and messaging computer 
systems. The new company—Secure Information Systems 
Ltd. (SISL)—already has a portfolio of major contracts 
from the Minstry of Defence, civil departments and com¬ 
merce. 

A new range of science computer software packages for 
science classes in secondary schools is featured in BT’s 
1988/89 Education Resource catalogue. The software, 
aimed at 15-18 year olds, gives pupils real-life problems to 
solve and is intended to bring some industrial applications 
into school syllabuses. As well as a range of brochures, 
posters and work packs, the catalogue gives details of edu¬ 
cational videos available for loan or purchase. The materials 
are designed to suit a wide ability range at both primary 
and secondary levels. Copies of the new resources catalogue 
are available free to schools and educational establishments 
from: British Telecom Education Service, PO Box 10, 
Wetherby, Yorkshire LS23 7EL. 

BT is also sponsoring a wide range of educational activities 
during 1988. A series of weekend workshops have been 
planned to provide some industrial dimension to in-service 
training for teachers as well as a teacher fellowship scheme 
to be run jointly with the Association for Science Education. 

bt has announced the following appointments: Mr. Barry 
Romeril to the Board of BT in the new post of Group 
Finance Director; Mr. David Day as Deputy Managing 
Director, UK Communications Division; Mr. Brian Rigby 
as Deputy Managing Director of British Telecom Enterpr¬ 
ises; Mr. Mike Armitage as Assistant Managing Director 
(Operations) of the UK Communications Division, and Mr. 
Kenwyn Brown as Director of British Telecom Property. 


76 


British Telecommunications Engineering , Vol. 7, April 1988 


Product News 


Marquis Executive Terminal 

BT has launched the new Marquis Executive Terminal. The 
new terminal, which combines an attractive new-look design 
with an enhanced loudspeech facility, has been developed 
by BT in response to customer need for a top-end executive 
loudspeaking featurephone. 

Marquis, a 6-line 12-extension key system, incorporates 
all the features expected of a modern telephone system. A 
Standard (monitor only) terminal is available, and the new 
Executive Terminal is aimed at business users who require an 
attractive terminal on their desk which also allows efficient 
hands-free working. The new Executive Terminal’s upgraded 
loudspeech facility has been achieved by using new circuitry. 
Busy executives can now enjoy clear hands-free conversation 
even several feet away from their desks. The added benefit 
of this facility is that it allows several people to have a group 
discussion via the same telephone. The loudspeaker and 
mini-microphone are neatly integrated into the new ter¬ 
minal’s sleek low-profile styling. 

The terminal also features, as part of its new look, an 
improved key-pad layout which makes press-button dialling 
quicker and simpler. The tone-caller volume control has also 
been repositioned to make it easier to manage and adjust. 
The terminal also features call transfer and hold; automatic 



BT’s new Marquis Executive Terminal 

return to calls on hold; up to 16 telephone numbers can be 
stored and subsequently dialled at the touch of a few buttons; 
automatic last number redial; on-hook dialling, enabling one 
to carry on working until the call is answered; conference 
call facility; a paging facility; and call barring. 


All-CMOS High-Temperature STEbus 

The first all-CMOS processor board for the STEbus has 
been announced by British Telecom Microprocessor Sys¬ 
tems. Based on Intel’s 8031 CPU with CMOS memory and 
input/output (I/O), the minimal power consumption and 
inherent noise immunity of the board makes it ideally suited 
to the implementation of computer systems for battery- 
powered or harsh-environment applications. 

The board, designated the 4040-00 , accepts up to 32K 
ROM and 32K RAM, and offers 24 lines of digital I/O, 
two 16 bit counter-timers, two external interrupts, a battery- 
backed real-time clock with watch-dog timer, and power- 
fail circuitry. I/O facilities are brought out on a ribbon- 


Processor 

cable connector conforming to the STE industry-standard 
‘signal-conditioning bus’ scheme, which allows connection 
to a wide variety of real-world off-the-shelf interfaces. 

The 4040-00 operates over —40 to +85°C, working from 
a single 5 V supply and consuming just 40 mA. Combined 
with CMOS technology’s excellent noise immunity, the 
board is an ideal basis for the design of computer system 
applications such as remote data loggers, factory-floor data 
collection terminals or portable test instrumentation. 
Remote applications are supported by BT’s STEbus modem 
for connection to the public-switched telephone network. 


Computing on the Move 



British Telecom’s M5183 Personal Computer 


A new powerful portable computer—no bigger than a brief¬ 
case—has been added to British Telecom’s growing M5000 
computer range. The M5183 is a hard-disc version of the 


popular M5181 laptop with a massive storage capacity 
comparable to a conventional desk-top computer. Ideal for 
people who need to process data but do not always have 
access to the office computer, the new laptop computer 
weighs less than 16 lb and can be carried easily by its built- 
in handle. It is supplied complete with a rechargeable battery 
pack for use when travelling, and a mains power supply 
adapter. 

The M5183 has a dual-speed processor and 640 Kbyte 
memory sufficient for all MS-DOS applications. The 
20 Mbyte hard disc gives the M5183 huge storage capacity 
for running a full complement of application programmes 
with power to spare for storing a large database. The 
3-5 inch 720 Kbyte floppy disc provides twice the storage 
capacity of its 5 • 25 inch predecessor as well as being more 
robust and reliable. A full-size illuminated screen gives 
outstanding display and can be fitted and adjusted for 
brightness and contrast. 

An optional internal modem enables the computer to be 
used to access remote computer systems. An additional 
adaptor enables the user to send data from a car or portable 
telephone over the cellular network. 
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New High-Performance Low-Cost Transmission Systems from British Telecom 
International Products 


British Telecom International Products has developed the 
BT System 2, a new optical fibre digital line system for short- 
haul 2 Mbit/s transmission. BT System 2 gives unsurpassed 
performance at very low cost; this makes it ideal for a wide 
variety of data transmission functions including telephone 
network local-line access, inter- and intra-office communi¬ 
cations, computer-to-computer links, and local area net¬ 
working. 

Each BT System 2 line system comprises two line termi¬ 
nating units (LTUs), which are interconnected by a pair of 
optical fibres, one for each direction of transmission. By 
adopting the CCITT-specified HDB3 interface code for 
transmission over the optical path, a 2 Mbit/s signal achieves 
the desired system requirements of signal transparency, 
adequate timing information and error monitoring. 

The BT System 2 line transmission system can operate 
over both single-mode and multimode graded index, optical- 
fibre pairs, without the need for optical attenuators. Single¬ 
mode transmission caters for distances up to 5 km with 
9/125 optical fibre, whilst multimode operates up to 10 km 
with 50/125 optical fibre. 

BT System 2 is packaged in a TEP-1E equipment shelf 
which can accommodate eight separate LTUs, together with 
an alarm interface card and an optional shelf-interconnec¬ 
tion card. Each LTU has its own power supply for improved 
fail-safe operation, with the DC power supply distributed 
via the shelf backplane. The shelf backplane design excludes 
any active components and has been specially constructed 
to help overcome the operational problems associated with 
radio-frequency interference susceptibility. BT System 2 
meets BS6527 Class B for the emission of spurious signals. 

The unit provides users with sophisticated system moni¬ 
toring and supervisory features to ensure fail-safe operation. 
LTU status is checked 1000 times per second, and ten 
separate alarm lights, each with a lamp-lock facility, give 
visual indication of transient fault conditions, such as power- 
off, signal failure and far-end fault. Transmission perform¬ 
ance monitoring can also be provided by replacing the alarm 
interface card with a central network monitoring interface. 

Advanced end-to-end supervisory features provided by BT 
System 2 include alarm extension, remote loop back and 
user-definable end-to-end flags. 

Alarm extension is a switchable option which provides 
more information about the fault status of remote LTUs, 
allowing unmanned stations to be monitored effectively. 
Remote loop back is another switchable option on each LTU 
which enables the traffic path to be looped back at the 
remote unit to isolate possible transmission faults. This 
feature is especially useful for installation checking, and is 
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software-controllable for central network monitoring. End- 
to-end flagging is a user-definable facility which uses BT 
System 2’s four specifiable inputs, refreshed once a second, 
to monitor or control remotely sited equipment. 

Each LTU is manufactured to the highest standards, and 
is protected by a metal housing to ensure EMC and ESD 
protection both during manufacture and in service. The 
electrical interface of the LTU provides for transparent 
transmission of 2048 kbit/s HDB3-encoded PCM or com¬ 
puter data traffic, and conforms to CCITT Recommen¬ 
dations G.703, G.823 and G.921. The optical source is an 
880 nm LED suitable for both 9/125 single-mode and 
50/125 multimode optical-fibre types. Physical connection 
is via two STRATOS optical connectors. 

BT System 2 and the TEP-1E equipment shelf are particu¬ 
larly easy to install, and LTU replacement and servicing 
can be completed on-site within an hour. 


X.400 Electronic Messaging Application 


PC400 is BT’s new X.400 electronic messaging application 
for PC local area networks (LANs), based on the inter¬ 
national X.400 standard. PC400 marks a significant break¬ 
through in the expanding LAN environment, being the first 
X.400 messaging application available on microcomputer- 
based LAN systems. 

Running on BT’s M5000 PC range or other IBM compat¬ 
ibles, PC400 operates under Novell’s Netware on BT’s 
T-Net 1000 series of LAN solutions. PC400, which was 
developed by BT at its Martlesham Heath Research Labora- 
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tories, is a powerful messaging application that gives users 
national and international access to other X.400 systems. 

PC400 gives users access to a wide range of communi¬ 
cations facilities including electronic mail via a user-friendly 
icon interface. In addition, PC400 provides secure trans¬ 
mission, delivery notification, originator identification, as 
well as the concept of envelope and contents. PC400 also 
gives users access to X.400-related public messaging services 
including Gold 400. Via the X.400 gateway, users can send 
into, and receive messages from, this comprehensive service. 
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Book Reviews 


Memoirs of a Telecommunications Engineer 
John Bray. 

199 pp. 39 ills. £7-00. 

This book, by a former Director of Research of the Post 
Office (now British Telecom), spans the period from the 
1920s to 1975—a period he describes as ‘one of the most 
exciting and significant in the history of telecommuni¬ 
cations’. 

It gives a first-hand account of people and events that have 
led to major technological advances in telecommunications, 
ranging from pre-war developments in short-wave radio; 
electronic warfare; the evolution of microwave radio-relay 
inter-city systems, transoceanic submarine cables and opti¬ 
cal-fibre systems; the progression from electro-mechanical 
to computer-controlled electronic exchange switching sys¬ 
tems; to the beginnings of satellite communication. 

A side-line in the story describes how the timely creation 
of the first Post Office television receiver detection van 
saved a Postmaster General from some embarrassment and 
brought in millions of pounds of additional license revenue. 

During the period covered by the Memoirs, there were 
advances in device technology of immense significance, 
including the transistor and the micro-chip, and the revol¬ 
utionary move forward from analogue to digital transmission 
and switching. It was a period when the telegraph/telephone 
service expanded its horizons to include data communi¬ 
cations and new visual telecommunication services such as 
Prestel and conference television. The full implication of 
these advances—and the growth of information technology 
generally—on the way people live, work and use their leisure 
has yet to be felt. 

This book is not a formal history of the period: it is 
essentially one man’s account of the people and developments 
that he was fortunate enough to observe at close hand, and 
the sometimes strange and fortuitous events that decided 
the shape of things to come. 

This book is available from the Journal office; see the 
advertisement on p. 80 for details. 


Goal Directed Project Management 

Erling S. Anderson, Kristoffer V. Grude, Tor Haug, and 

J. Rodney Turner. 

Kogan Page. 196 pp. 40 ills. £16-95. 

ISBN 1-85091-315-3. 

There is hardly any sphere of activity nowadays which does 
not have as a vital topic the problems of change. The need 
for change evokes a range of reactions from exhilaration, 
through resistance, to panic; but it does not go away. To be 
successful, any change must be managed with care and led 
with skill. 

This book sets out from the basic premise that any project, 
whatever its objective, creates change of some sort. The vast 
majority of projects require changes in a company’s people 
(numbers, skills, competencies), systems (the way the com¬ 
pany works and uses its technology) and organisation (the 
structure that supports the procedures). Ignoring these 
requirements in the initial planning stages either spells the 
death of many potentially good projects and the waste of so 
much effort and expertise or results in frantic fire-fighting 
in the later stages to save the project. 

The eleven chapters of the book cover project character¬ 


istics; pitfalls in project management; planning, organising 
and co-ordinating the elements of milestones, roles, responsi¬ 
bilities and activities. They also address the vital questions 
of control and leadership. Although the authors are fairly 
economical with the prose (no bad thing), they build in 
reviews and summaries at various stages to ensure that 
messages are not lost. Ample diagrams and illustrations of 
completed report forms demonstrate how the paperwork 
attached to projects need not be voluminous but can carry 
all the vital information required at different levels. The 
usefulness of computers in project management is recog¬ 
nised, as is the danger of assuming that they will substitute 
for proper management. The authors have therefore pro¬ 
ceeded on a ‘manual’ basis throughout the book, leaving 
readers to choose whatever software package they deem 
appropriate once they have a clear understanding of the 
needs to be achieved. 

Apart from the detailed steps that the book takes us 
through regarding, for instance, the planning and scheduling 
stages, several key messages come across loud and clear. 
Firstly, the selection and development of the project leader 
is not something to be taken lightly; the role is much more 
difficult than management of the steady state and requires 
specialist skills and knowledge. Managing change is a com¬ 
plex task and it needs skilled people. Secondly, proper 
training must be scheduled in, not only for the project 
members, but also for the staff who are going to be part of 
the change—otherwise its implementation will be flawed. 
Thirdly, projects must be properly managed as opposed to 
allowing the team to get caught in a vicious circle of 
continuous re-planning. Lastly, careful thought must be 
given before deciding to appoint a management group to 
which the project leader has to report. On occasion this 
could lead to unnecessary diffusion of responsibility; the 
leader should take his/her remit from, and report to, the 
owner of the problem even if it is the managing director. 

The authors state that the book is aimed at project 
managers and project members and the concepts are illus¬ 
trated with examples taken from projects on which the 
authors themselves have worked. I would, however, widen 
the audience to many managers of the ‘steady state’, who 
realise that change is nigh. Familiarisation with the concepts 
and procedures of project management as laid out in this 
book should lead to managers realising that change itself, 
whether cultural, procedural or technical can, or ought to 
be, project managed into their own area of responsibility 
and thereby avoiding a lot of the confusion and resentment 
that would otherwise arise. 

The four authors are very credible in terms of credentials 
and their practical experience shows through. The only real 
criticism I have of the book is the authors’ decision to 
allocate the whole of chapter 3 to dire warnings about 
potential pitfalls. Coming so early in the book, before the 
respective words of wisdom on each topic, gave the same 
feel as those old maps of Africa where vast tracts of 
uncharted land were covered with the sinister words: ‘Hie 
sunt Leones /’ (Here there are lions!). I cannot help feeling 
that the admonitions would have had better effect by being 
separated out and placed at the end of the relevant chapters. 
Nevertheless, this book is well worth reading and then 
keeping for reference. It is not a comprehensive study of 
all project management knowledge and practice, but if 
managers had only this book to go on, it would be very 
difficult to come up with valid excuses for not achieving 
their project goals. 

D. P. O’Donovan 
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John Bray 

(Reviewed in this Journal on p. 79) 
Former Director of Research, John Bray, 
provides a fascinating and personal account of 
progress in telecommunications from the 
1920s to 1975. 
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AT&T and Philips Telecommunications 




prehensive, versatile system currently available. 

It incorporates a number of novel features which may 
be combined into different configurations, tailored to the 
needs of the individual user, however large or small. 

It means that every connection is successful, regardless 
of time, traffic or staff. APT is one of the very few companies 
with the capacity creativity and resources to handle such 
projects, even on a turnkey basis both now and well into the 
21 st Century. If you want to know more about APT's work 
and how it can affect your future, ask us for our brochure. 

AT&T and Philips Telecommunications UK Ltd., Swindon 
Road, Malmesbury, Wiltshire, England SN16 9NA. Telephone: 
(0666) 822861. Fax: (0666) 824515 Telex: 44208 APTMAL G 


"ADVANCED TECHNOLOGY FROM APT IS THE 
MOST COMPREHENSIVE AVAILABLE 
TODAY AND HAS MADE ADVANCED LINKLINE 
_ POSSIBLE: (BRITISH TELECOM). _ 

The advanced LinkLine freephone service is a highly effective 
marketing tool, creating new business opportunities both 
for British users and British Telecom. It provides freephone 
calls to subscribers, so increasing orders, generating sales 
leads and allowing the introduction of many new services. 

Advanced LinkLine, employing the advanced 
5ESS-PRX digital exchanges from AT&T and Philips Tele¬ 
communications (APT), was evaluated as the most com- 
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